Re: [PATCH 5/5] Export the temperatures via hwmon
On 08/07/2014 01:18 AM, Guenter Roeck wrote:
> On Wed, Aug 06, 2014 at 09:05:03PM +, Goffredo Baroncelli wrote:
>> From: Goffredo Baroncelli
>>
>> Export the temperature via the hwmon subsystem.
>> See the list below for the sensors exported:
>>
>> $ cd /sys/devices/temperature/hwmon/hwmon0
>> $ echo "name: $(cat name)"; for i in temp*; do echo "$i: $(cat $i)"; done
>> name: therm_windtunnel
>> temp1_input: 59312
>> temp1_label: CPU
>> temp2_input: 36750
>> temp2_label: Case
>> temp3_input: 37750
>> temp3_label: Case2
>>
> Makes me wonder why you don't report the fan speed through hwmon.
See the first email. Basically when I start to read the fan speed,
it became irregular, so I stopped the test. I don't know
if it is a my faulted hardware, or an hw design problem.
The fan is a 2 wire fan.
>
>> The Case2 temperature is the sensor temperature inside the adm1030.
>>
> There are standard hwmon drivers for lm75, ds1775, and adm1030.
> Personally I think it would make more sense to use those directly.
> But I guess that would be for another day.
>
>> Signed-off-by: Goffredo Baroncelli
>> ---
>> drivers/macintosh/therm_windtunnel.c | 103
>> +--
>> 1 file changed, 99 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/macintosh/therm_windtunnel.c
>> b/drivers/macintosh/therm_windtunnel.c
>> index b6cba98..a6757d7 100644
>> --- a/drivers/macintosh/therm_windtunnel.c
>> +++ b/drivers/macintosh/therm_windtunnel.c
>> @@ -37,6 +37,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include
>> #include
>> @@ -58,9 +60,12 @@ static struct {
>> struct i2c_client *thermostat;
>> struct i2c_client *fan;
>>
>> +struct device *hwmon;
>> +
>> int overheat_temp; /* 100% fan at this
>> temp */
>> int overheat_hyst;
>> int temp;
>> +int casetemp2;
>> int casetemp;
>> int fan_level; /* active fan_table
>> setting */
>>
>> @@ -120,6 +125,75 @@ static DEVICE_ATTR(case_temperature, S_IRUGO,
>> show_case_temperature, NULL );
>> static DEVICE_ATTR(fan_level, S_IRUGO, show_fan_level, NULL);
>>
>>
>> +static ssize_t
>> +show_temp1(struct device *dev, struct device_attribute *attr, char *buf)
>> +{
>> +return sprintf(buf, "%d%03d\n", x.temp>>8, (x.temp & 0xff)*1000>>8);
>
> I personally prefer if code follows coding style, with spaces around operands,
> and if calculations are less cryptic.
>
>> +}
>> +
>> +static ssize_t
>> +show_temp1_label(struct device *dev, struct device_attribute *attr, char
>> *buf)
>> +{
>> +return sprintf(buf, "CPU\n");
>> +}
>> +
>> +static ssize_t
>> +show_temp2(struct device *dev, struct device_attribute *attr, char *buf)
>> +{
>> +return sprintf(buf, "%d%03d\n", x.casetemp>>8,
>> +(x.casetemp & 0xff)*1000>>8);
>> +}
>> +
>> +static ssize_t
>> +show_temp2_label(struct device *dev, struct device_attribute *attr, char
>> *buf)
>> +{
>> +return sprintf(buf, "Case\n");
>> +}
>> +
>> +
>> +static ssize_t
>> +show_temp3(struct device *dev, struct device_attribute *attr, char *buf)
>> +{
>> +return sprintf(buf, "%d%03d\n", x.casetemp2>>8,
>> +(x.casetemp2 & 0xff)*1000>>8);
>
> ... and aligned second lines.
>
>> +}
>> +
>> +static ssize_t
>> +show_temp3_label(struct device *dev, struct device_attribute *attr, char
>> *buf)
>> +{
>> +return sprintf(buf, "Case2\n");
>> +}
>> +
>> +#define TWT_ATTRIB(name, func) \
>> +static SENSOR_DEVICE_ATTR(name##_input, S_IRUGO, func, NULL, 0); \
>> +static SENSOR_DEVICE_ATTR(name##_label, S_IRUGO, func##_label, \
>> +NULL, 0)
>> +
>> +TWT_ATTRIB(temp1, show_temp1);
>> +TWT_ATTRIB(temp2, show_temp2);
>> +TWT_ATTRIB(temp3, show_temp3);
>> +
>> +
> A single empty line should be sufficient. Personally I am also not
> a fan of such macros (and neither is checkpatch), and prefer the use
> of direct macros as less confusing.
True, I put a three line macro to avoid to write three line... it
doesn't make sense.
>
> Also, using three different functions for three different attributes
> where the only difference is the variable name defeats the purpose
> of using SENSOR_DEVICE_ATTR, which has an index variable for exactly
> that reason. I would suggest to either use an indexed array to access
> the temperatures, or use DEVICE_ATTR.
>
>> +static struct attribute *therm_windtunnel_attributes[] = {
>> +_dev_attr_temp1_input.dev_attr.attr,
>> +_dev_attr_temp1_label.dev_attr.attr,
>> +_dev_attr_temp2_input.dev_attr.attr,
>> +_dev_attr_temp2_label.dev_attr.attr,
>> +_dev_attr_temp3_input.dev_attr.attr,
>> +_dev_attr_temp3_label.dev_attr.attr,
>> +
>> +NULL,
>> +};
>> +
>> +static const struct attribute_group therm_windtunnel_attr_group
Re: [PATCH 02/15] cpufreq: fix decimal printf format specifiers prefixed with 0x
On 08/06/2014 01:35 PM, Rafael J. Wysocki wrote: On Tuesday, August 05, 2014 09:41:48 PM Hans Wennborg wrote: The prefix suggests the number should be printed in hex, so use the %x specifier to do that. Found by using regex suggested by Joe Perches. Signed-off-by: Hans Wennborg This triggers a build warning related to the formats. Care to fix up? Sure. Sending a new patch, hopefully attached to the same thread (still working on my git send-mail skills). - Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cpufreq: fix decimal printf specifiers prefixed with 0x
The prefix suggests the number should be printed in hex, so use
the %x specifier to do that. Also, these are 32-bit values,
so drop the l characters.
Signed-off-by: Hans Wennborg
---
drivers/cpufreq/speedstep-smi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
index 8635eec..5fc96d5 100644
--- a/drivers/cpufreq/speedstep-smi.c
+++ b/drivers/cpufreq/speedstep-smi.c
@@ -324,8 +324,8 @@ static int __init speedstep_init(void)
return -ENODEV;
}
- pr_debug("signature:0x%.8ulx, command:0x%.8ulx, "
- "event:0x%.8ulx, perf_level:0x%.8ulx.\n",
+ pr_debug("signature:0x%.8x, command:0x%.8x, "
+ "event:0x%.8x, perf_level:0x%.8x.\n",
ist_info.signature, ist_info.command,
ist_info.event, ist_info.perf_level);
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [media] dvb: return the error from i2c_transfer if negative
Signed-off-by: Hans Wennborg --- drivers/media/dvb-frontends/mb86a16.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/dvb-frontends/mb86a16.c b/drivers/media/dvb-frontends/mb86a16.c index 1f7fce7..0e65d35 100644 --- a/drivers/media/dvb-frontends/mb86a16.c +++ b/drivers/media/dvb-frontends/mb86a16.c @@ -118,6 +118,8 @@ static int mb86a16_read(struct mb86a16_state *state, u8 reg, u8 *val) dprintk(verbose, MB86A16_ERROR, 1, "read error(reg=0x%02x, ret=%i)", reg, ret); + if (ret < 0) + return ret; return -EREMOTEIO; } *val = b1[0]; -- 2.0.0.526.g5318336 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [media] dvb: remove 0x prefix from decimal value in printf
Signed-off-by: Hans Wennborg
---
drivers/media/dvb-frontends/mb86a16.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/mb86a16.c
b/drivers/media/dvb-frontends/mb86a16.c
index 9ae40ab..1f7fce7 100644
--- a/drivers/media/dvb-frontends/mb86a16.c
+++ b/drivers/media/dvb-frontends/mb86a16.c
@@ -115,7 +115,7 @@ static int mb86a16_read(struct mb86a16_state *state, u8
reg, u8 *val)
};
ret = i2c_transfer(state->i2c_adap, msg, 2);
if (ret != 2) {
- dprintk(verbose, MB86A16_ERROR, 1, "read error(reg=0x%02x,
ret=0x%i)",
+ dprintk(verbose, MB86A16_ERROR, 1, "read error(reg=0x%02x,
ret=%i)",
reg, ret);
return -EREMOTEIO;
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scsi: Check if WSR already defined
On xtensa arch there is this warning
drivers/scsi/sym53c8xx_2/sym_defs.h:109:0: warning: "WSR" redefined [enabled by
default]
arch/xtensa/include/asm/processor.h:188:0: note: this is the location of the
previous definition
I can remove WSR since it is not being used but more documentation purpose, so
undefining is enough.
Signed-off-by: Nick Krause
---
drivers/scsi/sym53c8xx_2/sym_defs.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/scsi/sym53c8xx_2/sym_defs.h
b/drivers/scsi/sym53c8xx_2/sym_defs.h
index defccc4..68334a5 100644
--- a/drivers/scsi/sym53c8xx_2/sym_defs.h
+++ b/drivers/scsi/sym53c8xx_2/sym_defs.h
@@ -91,6 +91,10 @@ struct sym_chip {
#define FE_CACHE0_SET (FE_CACHE_SET & ~FE_ERL)
};
+#ifdef WSR
+#undef WSR
+#endif
+
/*
* SYM53C8XX IO register data structure.
*/
--
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] Staging: rtl8192u: fix sparse warnings in r8192U_core.c
On Thu, Aug 07, 2014 at 10:10:47AM +0530, A Raghavendra Rao wrote: > Fix the following sparse warnings: > drivers/staging/rtl8192u/r8192U_core.c:670:6: warning: symbol 'dump_eprom' > was not declared. Should it be static? > drivers/staging/rtl8192u/r8192U_core.c:1556:14: warning: symbol > 'txqueue2outpipe' was not declared. Should it be static? > drivers/staging/rtl8192u/r8192U_core.c:4876:5: warning: symbol > 'GetRxPacketShiftBytes819xUsb' was not declared. Should it be static? > > Signed-off-by: A Raghavendra Rao > --- > drivers/staging/rtl8192u/r8192U_core.c | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/rtl8192u/r8192U_core.c > b/drivers/staging/rtl8192u/r8192U_core.c > index 7640386..6ad767a 100644 > --- a/drivers/staging/rtl8192u/r8192U_core.c > +++ b/drivers/staging/rtl8192u/r8192U_core.c > @@ -667,12 +667,14 @@ static void tx_timeout(struct net_device *dev) > > > /* this is only for debug */ > -void dump_eprom(struct net_device *dev) > +#ifdef DEBUG_EPROM You can't define this, so just delete the whole thing. Wait, didn't someone already do this? Yes, someone just sent me this same thing on the 1st, it's in my queue to apply after 3.17-rc1 is out. Sorry, I can't take this. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtl8150: Check if RSR is already defined
From: Nick Krause Date: Thu, 7 Aug 2014 07:24:54 +0200 > I am getting the following warn > > drivers/net/usb/rtl8150.c:30:0: warning: "RSR" redefined > arch/xtensa/include/asm/processor.h:189:0: note: this is the location of the > previous definition > > I wanted to remove RSR as it is not being used but it is not clear if being > used > for documenting purpose. undefining should be enough. > > Signed-off-by: Nick Krause This isn't the right way to fix this. Rather, the thing to do is to give the macros in this driver an appropriate prefix such as "RTL8150_" so that they don't collide with things in the global namespace. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Guten Tag,
Guten Tag, Meine Namen sind Thaung Lin Yan ein kanadischer Staatsbürger in Asien und ein Konto Offizier Manager für Wei Gu Steel Company seit 23 Jahren. Wei Gu Stahl Angebote für die Herstellung von verschiedenen Stahl in Hong Kong und wir haben auch ein Vertriebsbüro in China. Ich bin in der Notwendigkeit einer Vertrauens würdig Person, die mir helfen Fonds bewegen sich in der Höhe von $ 250.000.000,00 (Zwei hundertfünfzig Millionen USD). Unser Unternehmen wird sich sehr bald Falten und ich brauche, um die oben genannten Mittel aus dem Unternehmen entfallen auf eine gesicherte Bank zu bewegen. Das ist 150% risikofrei und Sie werden zu 20% der Gesamtmittel nach Abschluss berechtigt. Bei Interesse wenden Sie sich bitte zurück zu mir, so besagt für weitere Details. Geben Sie mir auch mit den Details unten so schnell wie möglich. 1. Volle Namen 2. Adresse 3. Land 4. Alter 5. Telefonnummern 6. Beruf Bitte beachten Sie, nur seriöse Personen benötigt. Mit freundlichen Grüßen. Thaung Lin Yan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] usbip: move usbip out of staging
On Thu, Aug 07, 2014 at 08:10:25AM +0300, Valentina Manea wrote: > This is a resend of the patch series from March. > > After migrating userspace code to libudev, converting usbip-host > to a device driver and various bug fixes and enhancements, USB/IP > is fully functional and can be moved out of staging. > > This patch series moves it as following: > * userspace code to tools/usb/usbip > * kernel code to drivers/usb/usbip > > Besides this, a warning generated in the kernel code is solved. What kernel version is this against? And can we get a maintainer for this code? I don't want to see it sit "ownerless" in the kernel tree. Will you be willing to do this? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 1/2] i2c: imx: add DMA support for freescale i2c driver
From: Yuan Yao-B46683 Data: Wednesday, August 06, 2014 3:07 PM
>To: Duan Fugang-B38611; w...@the-dreams.de; ma...@denx.de
>Cc: l...@karo-electronics.de; mark.rutl...@arm.com; shawn@linaro.org;
>linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
>i...@vger.kernel.org; Li Frank-B20596
>Subject: RE: [PATCH v6 1/2] i2c: imx: add DMA support for freescale i2c
>driver
>
>Hi Fugang,
>
>Duan Fugang wrote:
>[...]
>>+ dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
>>+ dma_sconfig.dst_maxburst = 1;
>> The maxburst is 1 cause very slow efficiency for DMA copy, which
>> system performance even is slower Than cpu mode.
>
>There is no FIFO for IMX i2c, so the maxburst shoud be 1 for hardware
>request.
>
Understand. Thanks.
>
>> >+ /* Waiting for Transfer complete. */
>> >+ while (timeout--) {
>> >+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
>> >+ if (temp & I2SR_ICF)
>> >+ break;
>> >+ udelay(10);
>> >+ }
>> Whether there have better method like interrupt to avoid dead wait
>> here until timeout ?
>
>Can you give me more suggestion? We have discussed it with our team, It
>seems the short query wait is necessary.
>
At least, you can use schdule_timeout() instead of udelay() ?
>> >+
>> >+ if (!timeout)
>> >+ return -ETIMEDOUT;
>> >+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
>> >+ temp &= ~I2CR_DMAEN;
>> >+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
>> >+
>> >+ /* The last data byte must be transferred by the CPU. */
>> >+ imx_i2c_write_reg(msgs->buf[msgs->len-1],
>> >+ i2c_imx, IMX_I2C_I2DR);
>> >+ result = i2c_imx_trx_complete(i2c_imx);
>> >+ if (result)
>> >+ return result;
>> I don't understand why the last data need to be transmited by cpu. I
>> guess you want to get IIF interrupt ?
>
>Yes, we need the interrupt to do some mop-up.
>
>Also follow the hardware request as:
>
>The following flow diagram details exactly the operation for using a DMA
>controller to transmit "n" data bytes to a slave. The first byte (the
>slave calling address) is always transmitted by the CPU. All subsequent
>data bytes (apart from the last data byte) can be transferred by the DMA
>controller. The last data byte must be transferred by the CPU.
>
>> >+
>> >+ result = i2c_imx_acked(i2c_imx);
>> >+ if (result)
>> >+ return result;
>> >+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/15] rtlwifi: rtl8192de: fix decimal printf format specifiers prefixed with 0x
On 08/06/2014 07:38 AM, Larry Finger wrote: On 08/05/2014 11:43 PM, Hans Wennborg wrote: The prefix suggests the number should be printed in hex, so use the %x specifier to do that. Found by using regex suggested by Joe Perches. Signed-off-by: Hans Wennborg --- drivers/net/wireless/rtlwifi/rtl8192de/fw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/fw.c b/drivers/net/wireless/rtlwifi/rtl8192de/fw.c index 2317707..66e1760 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192de/fw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192de/fw.c @@ -234,7 +234,7 @@ static int _rtl92d_fw_init(struct ieee80211_hw *hw) rtl_read_byte(rtlpriv, FW_MAC1_READY)); } RT_TRACE(rtlpriv, COMP_FW, DBG_DMESG, -"Polling FW ready fail!! REG_MCUFWDL:0x%08ul\n", +"Polling FW ready fail!! REG_MCUFWDL:0x%08lx\n", rtl_read_dword(rtlpriv, REG_MCUFWDL)); return -1; } It would be best to actually build with your patches installed. This one yields the following warning: Terribly sorry about that, and thanks for catching it. I naively assumed that the code was correct besides the decimal vs. hex issue. CC [M] drivers/net/wireless/rtlwifi/rtl8192de/fw.o drivers/net/wireless/rtlwifi/rtl8192de/fw.c: In function ‘_rtl92d_fw_init’: drivers/net/wireless/rtlwifi/rtl8192de/fw.c:236:2: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘u32’ [-Wformat=] RT_TRACE(rtlpriv, COMP_FW, DBG_DMESG, ^ The format specifier should be %04x, not %08lx. Shouldn't it be %08x since it's a 32-bit value? > I have no idea why gcc did not complain as %08ul is also wrong. I assume the compiler would have warned about %08lu, but %08ul takes an unsigned and just prints an l afterwards. - Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rtl8150: Check if RSR is already defined
I am getting the following warn drivers/net/usb/rtl8150.c:30:0: warning: "RSR" redefined arch/xtensa/include/asm/processor.h:189:0: note: this is the location of the previous definition I wanted to remove RSR as it is not being used but it is not clear if being used for documenting purpose. undefining should be enough. Signed-off-by: Nick Krause --- drivers/net/usb/rtl8150.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c index 6e87e57..7d9a6ba 100644 --- a/drivers/net/usb/rtl8150.c +++ b/drivers/net/usb/rtl8150.c @@ -21,6 +21,10 @@ #define DRIVER_AUTHOR "Petko Manolov " #define DRIVER_DESC "rtl8150 based usb-ethernet driver" +#ifdef RSR +#undef RSR +#endif + #defineIDR 0x0120 #defineMAR 0x0126 #defineCR 0x012e -- 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] spi: Initialize variable to prevent uninitialized warning
On Thu, Aug 07, 2014 at 06:51:00AM +0200, Nick Krause wrote:
> While compiling we see the following waring
>
> drivers/spi/spi-bfin5xx.c: In function 'bfin_spi_pump_transfers':
> drivers/spi/spi-bfin5xx.c:695:6: warning: 'cr_width' may be used uninitialized
> in this function [-Wuninitialized]
>
> Initialize it to prevent the above warning
>
> Signed-off-by: Nick Krause
> ---
> drivers/spi/spi-bfin5xx.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-bfin5xx.c b/drivers/spi/spi-bfin5xx.c
> index ebf720b..f268bf4 100644
> --- a/drivers/spi/spi-bfin5xx.c
> +++ b/drivers/spi/spi-bfin5xx.c
> @@ -559,7 +559,7 @@ static void bfin_spi_pump_transfers(unsigned long data)
> struct spi_transfer *previous = NULL;
> struct bfin_spi_slave_data *chip = NULL;
> unsigned int bits_per_word;
> - u16 cr, cr_width, dma_width, dma_config;
> + u16 cr, cr_width = 0, dma_width, dma_config;
> u32 tranf_success = 1;
> u8 full_duplex = 0;
>
> @@ -648,7 +648,6 @@ static void bfin_spi_pump_transfers(unsigned long data)
> } else if (bits_per_word == 8) {
> drv_data->n_bytes = bits_per_word/8;
> drv_data->len = transfer->len;
> - cr_width = 0;
> drv_data->ops = _bfin_spi_transfer_ops_u8;
> }
So if we ever hit that uninitialized case, where bits_per_word is
neither 8 nor 16, we'll have ops set to NULL and end up wondering
why the kernel crashes a bit further down in the code. Not really
sure if that is an improvement.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] usbip: move usbip userspace code out of staging
At this point, USB/IP userspace code is fully functional
and can be moved out of staging.
Signed-off-by: Valentina Manea
---
{drivers/staging/usbip/userspace => tools/usb/usbip}/.gitignore | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/AUTHORS | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/COPYING | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/INSTALL | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/Makefile.am | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/README | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/autogen.sh | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/cleanup.sh | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/configure.ac | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbip.8 | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbipd.8 | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/Makefile.am | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/list.h| 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.h | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/sysfs_utils.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/sysfs_utils.h | 0
.../staging/usbip/userspace => tools/usb/usbip}/libsrc/usbip_common.c | 0
.../staging/usbip/userspace => tools/usb/usbip}/libsrc/usbip_common.h | 0
.../usbip/userspace => tools/usb/usbip}/libsrc/usbip_host_driver.c| 0
.../usbip/userspace => tools/usb/usbip}/libsrc/usbip_host_driver.h| 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/vhci_driver.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/vhci_driver.h | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/Makefile.am | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip.h | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_attach.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_bind.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_detach.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_list.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_network.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_network.h | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_port.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_unbind.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbipd.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/utils.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/utils.h | 0
37 files changed, 0 insertions(+), 0 deletions(-)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/.gitignore (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/AUTHORS (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/COPYING (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/INSTALL (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/Makefile.am (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/README (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/autogen.sh (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/cleanup.sh (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/configure.ac (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbip.8 (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbipd.8 (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/Makefile.am
(100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/list.h
(100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.c
(100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.h
(100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/sysfs_utils.c (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/sysfs_utils.h (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/usbip_common.c (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/usbip_common.h (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/usbip_host_driver.c (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/usbip_host_driver.h (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/vhci_driver.c (100%)
rename {drivers/staging/usbip/userspace =>
[PATCH 0/3] usbip: move usbip out of staging
After migrating userspace code to libudev, converting usbip-host
to a device driver and various bug fixes and enhancements, USB/IP
is fully functional and can be moved out of staging.
This patch series moves it as following:
* userspace code to tools/usb/usbip
* kernel code to drivers/usb/usbip
Besides this, a warning generated in the kernel code is solved.
Valentina Manea (3):
usbip: move usbip userspace code out of staging
usbip: move usbip kernel code out of staging
usbip: remove struct usb_device_id table
drivers/staging/Kconfig| 2 --
drivers/staging/Makefile | 1 -
drivers/{staging => usb}/usbip/Kconfig | 0
drivers/{staging => usb}/usbip/Makefile| 0
drivers/{staging => usb}/usbip/README | 0
drivers/{staging => usb}/usbip/stub.h | 0
drivers/{staging => usb}/usbip/stub_dev.c | 27 --
drivers/{staging => usb}/usbip/stub_main.c | 0
drivers/{staging => usb}/usbip/stub_rx.c | 0
drivers/{staging => usb}/usbip/stub_tx.c | 0
drivers/{staging => usb}/usbip/usbip_common.c | 0
drivers/{staging => usb}/usbip/usbip_common.h | 2 +-
drivers/{staging => usb}/usbip/usbip_event.c | 0
drivers/{staging => usb}/usbip/usbip_protocol.txt | 0
drivers/{staging => usb}/usbip/vhci.h | 0
drivers/{staging => usb}/usbip/vhci_hcd.c | 0
drivers/{staging => usb}/usbip/vhci_rx.c | 0
drivers/{staging => usb}/usbip/vhci_sysfs.c| 0
drivers/{staging => usb}/usbip/vhci_tx.c | 0
.../usbip/uapi => include/uapi/linux}/usbip.h | 0
.../usbip/userspace => tools/usb/usbip}/.gitignore | 0
.../usbip/userspace => tools/usb/usbip}/AUTHORS| 0
.../usbip/userspace => tools/usb/usbip}/COPYING| 0
.../usbip/userspace => tools/usb/usbip}/INSTALL| 0
.../userspace => tools/usb/usbip}/Makefile.am | 0
.../usbip/userspace => tools/usb/usbip}/README | 0
.../usbip/userspace => tools/usb/usbip}/autogen.sh | 0
.../usbip/userspace => tools/usb/usbip}/cleanup.sh | 0
.../userspace => tools/usb/usbip}/configure.ac | 0
.../userspace => tools/usb/usbip}/doc/usbip.8 | 0
.../userspace => tools/usb/usbip}/doc/usbipd.8 | 0
.../usb/usbip}/libsrc/Makefile.am | 0
.../userspace => tools/usb/usbip}/libsrc/list.h| 0
.../userspace => tools/usb/usbip}/libsrc/names.c | 0
.../userspace => tools/usb/usbip}/libsrc/names.h | 0
.../usb/usbip}/libsrc/sysfs_utils.c| 0
.../usb/usbip}/libsrc/sysfs_utils.h| 0
.../usb/usbip}/libsrc/usbip_common.c | 0
.../usb/usbip}/libsrc/usbip_common.h | 0
.../usb/usbip}/libsrc/usbip_host_driver.c | 0
.../usb/usbip}/libsrc/usbip_host_driver.h | 0
.../usb/usbip}/libsrc/vhci_driver.c| 0
.../usb/usbip}/libsrc/vhci_driver.h| 0
.../userspace => tools/usb/usbip}/src/Makefile.am | 0
.../userspace => tools/usb/usbip}/src/usbip.c | 0
.../userspace => tools/usb/usbip}/src/usbip.h | 0
.../usb/usbip}/src/usbip_attach.c | 0
.../userspace => tools/usb/usbip}/src/usbip_bind.c | 0
.../usb/usbip}/src/usbip_detach.c | 0
.../userspace => tools/usb/usbip}/src/usbip_list.c | 0
.../usb/usbip}/src/usbip_network.c | 0
.../usb/usbip}/src/usbip_network.h | 0
.../userspace => tools/usb/usbip}/src/usbip_port.c | 0
.../usb/usbip}/src/usbip_unbind.c | 0
.../userspace => tools/usb/usbip}/src/usbipd.c | 0
.../userspace => tools/usb/usbip}/src/utils.c | 0
.../userspace => tools/usb/usbip}/src/utils.h | 0
57 files changed, 1 insertion(+), 31 deletions(-)
rename drivers/{staging => usb}/usbip/Kconfig (100%)
rename drivers/{staging => usb}/usbip/Makefile (100%)
rename drivers/{staging => usb}/usbip/README (100%)
rename drivers/{staging => usb}/usbip/stub.h (100%)
rename drivers/{staging => usb}/usbip/stub_dev.c (90%)
rename drivers/{staging => usb}/usbip/stub_main.c (100%)
rename drivers/{staging => usb}/usbip/stub_rx.c (100%)
rename drivers/{staging => usb}/usbip/stub_tx.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.h (99%)
rename drivers/{staging => usb}/usbip/usbip_event.c (100%)
rename drivers/{staging => usb}/usbip/usbip_protocol.txt (100%)
rename drivers/{staging => usb}/usbip/vhci.h (100%)
rename drivers/{staging => usb}/usbip/vhci_hcd.c (100%)
rename drivers/{staging => usb}/usbip/vhci_rx.c (100%)
rename drivers/{staging => usb}/usbip/vhci_sysfs.c (100%)
rename drivers/{staging => usb}/usbip/vhci_tx.c (100%)
rename {drivers/staging/usbip/uapi => include/uapi/linux}/usbip.h (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/.gitignore (100%)
rename
[PATCH 2/3] usbip: move usbip kernel code out of staging
At this point, USB/IP kernel code is fully functional
and can be moved out of staging.
Signed-off-by: Valentina Manea
---
drivers/staging/Kconfig| 2 --
drivers/staging/Makefile | 1 -
drivers/{staging => usb}/usbip/Kconfig | 0
drivers/{staging => usb}/usbip/Makefile| 0
drivers/{staging => usb}/usbip/README | 0
drivers/{staging => usb}/usbip/stub.h | 0
drivers/{staging => usb}/usbip/stub_dev.c | 0
drivers/{staging => usb}/usbip/stub_main.c | 0
drivers/{staging => usb}/usbip/stub_rx.c | 0
drivers/{staging => usb}/usbip/stub_tx.c | 0
drivers/{staging => usb}/usbip/usbip_common.c | 0
drivers/{staging => usb}/usbip/usbip_common.h | 2 +-
drivers/{staging => usb}/usbip/usbip_event.c | 0
drivers/{staging => usb}/usbip/usbip_protocol.txt | 0
drivers/{staging => usb}/usbip/vhci.h | 0
drivers/{staging => usb}/usbip/vhci_hcd.c | 0
drivers/{staging => usb}/usbip/vhci_rx.c | 0
drivers/{staging => usb}/usbip/vhci_sysfs.c| 0
drivers/{staging => usb}/usbip/vhci_tx.c | 0
{drivers/staging/usbip/uapi => include/uapi/linux}/usbip.h | 0
20 files changed, 1 insertion(+), 4 deletions(-)
rename drivers/{staging => usb}/usbip/Kconfig (100%)
rename drivers/{staging => usb}/usbip/Makefile (100%)
rename drivers/{staging => usb}/usbip/README (100%)
rename drivers/{staging => usb}/usbip/stub.h (100%)
rename drivers/{staging => usb}/usbip/stub_dev.c (100%)
rename drivers/{staging => usb}/usbip/stub_main.c (100%)
rename drivers/{staging => usb}/usbip/stub_rx.c (100%)
rename drivers/{staging => usb}/usbip/stub_tx.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.h (99%)
rename drivers/{staging => usb}/usbip/usbip_event.c (100%)
rename drivers/{staging => usb}/usbip/usbip_protocol.txt (100%)
rename drivers/{staging => usb}/usbip/vhci.h (100%)
rename drivers/{staging => usb}/usbip/vhci_hcd.c (100%)
rename drivers/{staging => usb}/usbip/vhci_rx.c (100%)
rename drivers/{staging => usb}/usbip/vhci_sysfs.c (100%)
rename drivers/{staging => usb}/usbip/vhci_tx.c (100%)
rename {drivers/staging/usbip/uapi => include/uapi/linux}/usbip.h (100%)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 2c486ea..35b494f 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -28,8 +28,6 @@ source "drivers/staging/et131x/Kconfig"
source "drivers/staging/slicoss/Kconfig"
-source "drivers/staging/usbip/Kconfig"
-
source "drivers/staging/wlan-ng/Kconfig"
source "drivers/staging/comedi/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 1e1a3a1..e66a5db 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -6,7 +6,6 @@ obj-$(CONFIG_STAGING) += staging.o
obj-y += media/
obj-$(CONFIG_ET131X) += et131x/
obj-$(CONFIG_SLICOSS) += slicoss/
-obj-$(CONFIG_USBIP_CORE) += usbip/
obj-$(CONFIG_PRISM2_USB) += wlan-ng/
obj-$(CONFIG_COMEDI) += comedi/
obj-$(CONFIG_FB_OLPC_DCON) += olpc_dcon/
diff --git a/drivers/staging/usbip/Kconfig b/drivers/usb/usbip/Kconfig
similarity index 100%
rename from drivers/staging/usbip/Kconfig
rename to drivers/usb/usbip/Kconfig
diff --git a/drivers/staging/usbip/Makefile b/drivers/usb/usbip/Makefile
similarity index 100%
rename from drivers/staging/usbip/Makefile
rename to drivers/usb/usbip/Makefile
diff --git a/drivers/staging/usbip/README b/drivers/usb/usbip/README
similarity index 100%
rename from drivers/staging/usbip/README
rename to drivers/usb/usbip/README
diff --git a/drivers/staging/usbip/stub.h b/drivers/usb/usbip/stub.h
similarity index 100%
rename from drivers/staging/usbip/stub.h
rename to drivers/usb/usbip/stub.h
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
similarity index 100%
rename from drivers/staging/usbip/stub_dev.c
rename to drivers/usb/usbip/stub_dev.c
diff --git a/drivers/staging/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
similarity index 100%
rename from drivers/staging/usbip/stub_main.c
rename to drivers/usb/usbip/stub_main.c
diff --git a/drivers/staging/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
similarity index 100%
rename from drivers/staging/usbip/stub_rx.c
rename to drivers/usb/usbip/stub_rx.c
diff --git a/drivers/staging/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
similarity index 100%
rename from drivers/staging/usbip/stub_tx.c
rename to drivers/usb/usbip/stub_tx.c
diff --git a/drivers/staging/usbip/usbip_common.c
b/drivers/usb/usbip/usbip_common.c
similarity index 100%
rename from drivers/staging/usbip/usbip_common.c
rename to
[PATCH 0/3] usbip: move usbip out of staging
This is a resend of the patch series from March.
After migrating userspace code to libudev, converting usbip-host
to a device driver and various bug fixes and enhancements, USB/IP
is fully functional and can be moved out of staging.
This patch series moves it as following:
* userspace code to tools/usb/usbip
* kernel code to drivers/usb/usbip
Besides this, a warning generated in the kernel code is solved.
Valentina Manea (3):
usbip: move usbip userspace code out of staging
usbip: move usbip kernel code out of staging
usbip: remove struct usb_device_id table
drivers/staging/Kconfig| 2 --
drivers/staging/Makefile | 1 -
drivers/{staging => usb}/usbip/Kconfig | 0
drivers/{staging => usb}/usbip/Makefile| 0
drivers/{staging => usb}/usbip/README | 0
drivers/{staging => usb}/usbip/stub.h | 0
drivers/{staging => usb}/usbip/stub_dev.c | 27 --
drivers/{staging => usb}/usbip/stub_main.c | 0
drivers/{staging => usb}/usbip/stub_rx.c | 0
drivers/{staging => usb}/usbip/stub_tx.c | 0
drivers/{staging => usb}/usbip/usbip_common.c | 0
drivers/{staging => usb}/usbip/usbip_common.h | 2 +-
drivers/{staging => usb}/usbip/usbip_event.c | 0
drivers/{staging => usb}/usbip/usbip_protocol.txt | 0
drivers/{staging => usb}/usbip/vhci.h | 0
drivers/{staging => usb}/usbip/vhci_hcd.c | 0
drivers/{staging => usb}/usbip/vhci_rx.c | 0
drivers/{staging => usb}/usbip/vhci_sysfs.c| 0
drivers/{staging => usb}/usbip/vhci_tx.c | 0
.../usbip/uapi => include/uapi/linux}/usbip.h | 0
.../usbip/userspace => tools/usb/usbip}/.gitignore | 0
.../usbip/userspace => tools/usb/usbip}/AUTHORS| 0
.../usbip/userspace => tools/usb/usbip}/COPYING| 0
.../usbip/userspace => tools/usb/usbip}/INSTALL| 0
.../userspace => tools/usb/usbip}/Makefile.am | 0
.../usbip/userspace => tools/usb/usbip}/README | 0
.../usbip/userspace => tools/usb/usbip}/autogen.sh | 0
.../usbip/userspace => tools/usb/usbip}/cleanup.sh | 0
.../userspace => tools/usb/usbip}/configure.ac | 0
.../userspace => tools/usb/usbip}/doc/usbip.8 | 0
.../userspace => tools/usb/usbip}/doc/usbipd.8 | 0
.../usb/usbip}/libsrc/Makefile.am | 0
.../userspace => tools/usb/usbip}/libsrc/list.h| 0
.../userspace => tools/usb/usbip}/libsrc/names.c | 0
.../userspace => tools/usb/usbip}/libsrc/names.h | 0
.../usb/usbip}/libsrc/sysfs_utils.c| 0
.../usb/usbip}/libsrc/sysfs_utils.h| 0
.../usb/usbip}/libsrc/usbip_common.c | 0
.../usb/usbip}/libsrc/usbip_common.h | 0
.../usb/usbip}/libsrc/usbip_host_driver.c | 0
.../usb/usbip}/libsrc/usbip_host_driver.h | 0
.../usb/usbip}/libsrc/vhci_driver.c| 0
.../usb/usbip}/libsrc/vhci_driver.h| 0
.../userspace => tools/usb/usbip}/src/Makefile.am | 0
.../userspace => tools/usb/usbip}/src/usbip.c | 0
.../userspace => tools/usb/usbip}/src/usbip.h | 0
.../usb/usbip}/src/usbip_attach.c | 0
.../userspace => tools/usb/usbip}/src/usbip_bind.c | 0
.../usb/usbip}/src/usbip_detach.c | 0
.../userspace => tools/usb/usbip}/src/usbip_list.c | 0
.../usb/usbip}/src/usbip_network.c | 0
.../usb/usbip}/src/usbip_network.h | 0
.../userspace => tools/usb/usbip}/src/usbip_port.c | 0
.../usb/usbip}/src/usbip_unbind.c | 0
.../userspace => tools/usb/usbip}/src/usbipd.c | 0
.../userspace => tools/usb/usbip}/src/utils.c | 0
.../userspace => tools/usb/usbip}/src/utils.h | 0
57 files changed, 1 insertion(+), 31 deletions(-)
rename drivers/{staging => usb}/usbip/Kconfig (100%)
rename drivers/{staging => usb}/usbip/Makefile (100%)
rename drivers/{staging => usb}/usbip/README (100%)
rename drivers/{staging => usb}/usbip/stub.h (100%)
rename drivers/{staging => usb}/usbip/stub_dev.c (90%)
rename drivers/{staging => usb}/usbip/stub_main.c (100%)
rename drivers/{staging => usb}/usbip/stub_rx.c (100%)
rename drivers/{staging => usb}/usbip/stub_tx.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.h (99%)
rename drivers/{staging => usb}/usbip/usbip_event.c (100%)
rename drivers/{staging => usb}/usbip/usbip_protocol.txt (100%)
rename drivers/{staging => usb}/usbip/vhci.h (100%)
rename drivers/{staging => usb}/usbip/vhci_hcd.c (100%)
rename drivers/{staging => usb}/usbip/vhci_rx.c (100%)
rename drivers/{staging => usb}/usbip/vhci_sysfs.c (100%)
rename drivers/{staging => usb}/usbip/vhci_tx.c (100%)
rename {drivers/staging/usbip/uapi => include/uapi/linux}/usbip.h (100%)
rename {drivers/staging/usbip/userspace =>
[PATCH 3/3] usbip: remove struct usb_device_id table
This was used back when usbip-host was an interface device driver;
after the conversion to device driver, the table remained unused.
Remove it in order to stop receiving a warning about it.
Signed-off-by: Valentina Manea
---
drivers/usb/usbip/stub_dev.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index 51d0c71..fac20e0 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -26,33 +26,6 @@
#include "stub.h"
/*
- * Define device IDs here if you want to explicitly limit exportable devices.
- * In most cases, wildcard matching will be okay because driver binding can be
- * changed dynamically by a userland program.
- */
-static struct usb_device_id stub_table[] = {
-#if 0
- /* just an example */
- { USB_DEVICE(0x05ac, 0x0301) }, /* Mac 1 button mouse */
- { USB_DEVICE(0x0430, 0x0009) }, /* Plat Home Keyboard */
- { USB_DEVICE(0x059b, 0x0001) }, /* Iomega USB Zip 100 */
- { USB_DEVICE(0x04b3, 0x4427) }, /* IBM USB CD-ROM */
- { USB_DEVICE(0x05a9, 0xa511) }, /* LifeView USB cam */
- { USB_DEVICE(0x55aa, 0x0201) }, /* Imation card reader */
- { USB_DEVICE(0x046d, 0x0870) }, /* Qcam Express(QV-30) */
- { USB_DEVICE(0x04bb, 0x0101) }, /* IO-DATA HD 120GB */
- { USB_DEVICE(0x04bb, 0x0904) }, /* IO-DATA USB-ET/TX */
- { USB_DEVICE(0x04bb, 0x0201) }, /* IO-DATA USB-ET/TX */
- { USB_DEVICE(0x08bb, 0x2702) }, /* ONKYO USB Speaker */
- { USB_DEVICE(0x046d, 0x08b2) }, /* Logicool Qcam 4000 Pro */
-#endif
- /* magic for wild card */
- { .driver_info = 1 },
- { 0, } /* Terminating entry */
-};
-MODULE_DEVICE_TABLE(usb, stub_table);
-
-/*
* usbip_status shows the status of usbip-host as long as this driver is bound
* to the target device.
*/
--
1.8.1.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] sh: bug: add unreachable() to silence warnings
On Thu, Aug 07, 2014 at 03:42:20AM +0200, Nick Krause wrote:
> SuperH BUG() have warnings like
>
> kernel/sched/core.c:2692:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> net/core/ethtool.c:236:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>
> Other BUG() implementations
> have added unreachable() at end becuase of which I guess
> it does not showthese errors. We can silence them using unreachable().
>
> Signed-off-by: Nick Krause
This change seems reasonable to me. Unlike the generic version of
BUG(), this one doesn't call panic() or anything else flagged as
__noreturn, so it seems reasonable to add a call to unreachable() here
to tell the compiler that the assembly will trap and not return.
Reviewed-by: Josh Triplett
> arch/sh/include/asm/bug.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/sh/include/asm/bug.h b/arch/sh/include/asm/bug.h
> index dcf2780..1ae948f 100644
> --- a/arch/sh/include/asm/bug.h
> +++ b/arch/sh/include/asm/bug.h
> @@ -48,6 +48,7 @@ do {
> \
> "i" (__FILE__), \
> "i" (__LINE__), "i" (0), \
> "i" (sizeof(struct bug_entry))); \
> + unreachable(); \
> } while (0)
>
> #define __WARN_TAINT(taint) \
> --
> 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/
[git pull] Please pull powerpc.git next branch
Hi Linus ! First an apology ... a lot of the stuff in there was only very recently committed. This is not the normal process. I'm at fault here, my only excuse is having been insanely swamped with other things. That's one of the reasons for co-opting Michael as co-maintainer, to help with avoiding that sort of trainwreck in the future. The redeeming thing (if any) is that most of the patches were actually reviewed on patchwork for a while, went through several iterations, and in some cases fairly well tested in other places. Additionally the bulk of the "new" stuff is fairly platform specific with little risk of negatively impacting integration with other things. There's the VFIO bit that doesn't fit in that category, but I gave Alex the heads up already, he will probably send you some additional bits on top of it before the end of this week. Now for the content: This is the powerpc new goodies for 3.17. The short story: The biggest bit is Michael removing all of pre-POWER4 processor support from the 64-bit kernel. POWER3 and rs64. This gets rid of a ton of old cruft that has been bitrotting in a long while. It was broken for quite a few versions already and nobody noticed. Nobody uses those machines anymore. While at it, he cleaned up a bunch of old dusty cabinets, getting rid of a skeletton or two. Then, we have some base VFIO support for KVM, which allows assigning of PCI devices to KVM guests, support for large 64-bit BARs on "powernv" platforms, support for HMI (Hardware Management Interrupts) on those same platforms, some sparse-vmemmap improvements (for memory hotplug), There is the usual batch of Freescale embedded updates (summary in the merge commit) and fixes here or there, I think that's it for the highlights. Cheers, Ben. The following changes since commit 6f5405bc2ee0102bb3856e2cdea64ff415db2e0c: powerpc: use _GLOBAL_TOC for memmove (2014-07-22 15:56:04 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next for you to fetch changes up to 537e5400a0a05c4efe70e7b372c19cfcd0179362: powerpc/eeh: Export eeh_iommu_group_to_pe() (2014-08-07 13:00:02 +1000) Alexey Kardashevskiy (4): powerpc/powernv: Use it_page_shift for TCE invalidation powerpc/powernv: Use it_page_shift in TCE build powerpc/powernv: Add a page size parameter to pnv_pci_setup_iommu_table() powerpc/iommu: Fix comments with it_page_shift Andrey Utkin (1): powerpc/mm/numa: Fix break placement Andy Fleming (1): powerpc/e6500: Add support for hardware threads Anton Blanchard (3): powerpc/pseries: Use jump labels for hcall tracepoints powerpc/pseries: Optimise hcall tracepoints powernv: Add OPAL tracepoints Benjamin Herrenschmidt (5): Merge branch 'merge' into next Merge branch 'merge' into next Add Michael Ellerman as powerpc co-maintainer Merge remote-tracking branch 'scott/next' into next powerpc/eeh: Add missing #ifdef CONFIG_IOMMU_API Bharat Bhushan (1): booke/powerpc: define wimge shift mask to fix compilation error Brian W Hart (1): powerpc/powernv: Update dev->dma_mask in pci_set_dma_mask() path Chunhe Lan (2): t4240/dts: Enable third elo3 DMA engine support powerpc/85xx: Add T4240RDB board support Gavin Shan (17): powerpc/eeh: Avoid event on passed PE powerpc/eeh: EEH support for VFIO PCI device drivers/vfio: EEH support for VFIO PCI device powerpc/powernv: Fix IOMMU table for VFIO dev powerpc/eeh: Fetch IOMMU table in reliable way powerpc/eeh: Refactor EEH flag accessors powerpc/eeh: Selectively enable IO for error log powerpc/eeh: Reduce lines of log dump powerpc/eeh: Replace pr_warning() with pr_warn() powerpc/eeh: Make diag-data not endian dependent powerpc/eeh: Aux PE data for error log powerpc/powernv: Allow to freeze PE powerpc/powernv: Split ioda_eeh_get_state() powerpc/powernv: Handle compound PE powerpc/powernv: Handle compound PE for EEH powerpc/powernv: Handle compound PE in config accessors powerpc/eeh: Export eeh_iommu_group_to_pe() Guo Chao (1): powerpc/powernv: Enable M64 aperatus for PHB3 Himangi Saraogi (2): powerpc/mpic_msgr: Use kcalloc and correct the argument to sizeof powerpc/fsl-pci: Correct use of ! and & Laurentiu TUDOR (1): powerpc/85xx: drop hypervisor specific board compatibles Laurentiu Tudor (1): powerpc/booke64: wrap tlb lock and search in htw miss with FTR_SMT Li Zhong (4): powerpc: implement vmemmap_list_free() powerpc: implement vmemmap_remove_mapping() for BOOK3S powerpc: implement vmemmap_free() powerpc: start loop at section start of start in vmemmap_populated() Lucas Tanure (1): powerpc: Fix wrong defintion in boot/io.h Madhusudanan Kandasamy (1): powerpc: Fail
Re: [PATCH 1/1] bug: Add unreachable() to generic BUG() to silence warnings
On Thu, Aug 07, 2014 at 03:13:41AM +0200, Nick Krause wrote:
> Architectures which use generic BUG() have warnings like
>
> kernel/sched/core.c:2692:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> net/core/ethtool.c:236:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>
> Other BUG() implementations
> have added unreachable() at end but generic does not. I guess
> that is why
> it showing these errors. We can silence them using unreachable().
>
> Signed-off-by: Nick Krause
You shouldn't see those warnings. panic() has __noreturn set, which
should have exactly the same effect.
> include/asm-generic/bug.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 630dd23..effcc82 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -48,6 +48,7 @@ struct bug_entry {
> #define BUG() do { \
> printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
> panic("BUG!"); \
> + unreachable(); \
> } while (0)
> #endif
>
> --
> 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 v2 20/29] nios2: Cpuinfo handling
On Fri, Jul 18, 2014 at 10:43 AM, Ley Foon Tan wrote:
> On Tue, Jul 15, 2014 at 5:47 PM, Arnd Bergmann wrote:
>> On Tuesday 15 July 2014 16:45:47 Ley Foon Tan wrote:
>>> +static void *cpuinfo_start(struct seq_file *m, loff_t *pos)
>>> +{
>>> + unsigned long i = *pos;
>>> +
>>> + return i < num_possible_cpus() ? (void *) (i + 1) : NULL;
>>> +}
>>> +
>>> +static void *cpuinfo_next(struct seq_file *m, void *v, loff_t *pos)
>>> +{
>>> + ++*pos;
>>> + return cpuinfo_start(m, pos);
>>> +}
>>
>> Do you actually have SMP support?
> Not.
>
>
>>> +const struct seq_operations cpuinfo_op = {
>>> + .start = cpuinfo_start,
>>> + .next = cpuinfo_next,
>>> + .stop = cpuinfo_stop,
>>> + .show = show_cpuinfo
>>> +};
>>
>> If not, you can use single_start/next/stop here rather than defining your
>> own.
> Okay, I will look into your suggestion.
> Thanks.
I have tried this. But, it seem that we can't use
single_start/next/stop here. They are static functions to
fs/seq_file.c.
Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3] ftrace: Add a ftrace test collection
(2014/08/06 6:37), Steven Rostedt wrote: > Hi Masami, > > This looks great. I'm a bit busy at the moment (just came back from > vacation, and digging myself out of the hole that left me). But I > definitely want this in. I have a bunch of tests too, that I can put on > top of this. My tests are rather hacky, and hard code a lot of stuff in > them, but they do test a bunch of features of ftrace. It shouldn't be > too hard to include them here. Thanks! and I found some ftrace testcases in LTP, https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/tracing/ftrace_stress_test/ftrace_stress Most of them are for stress test, but basic ideas are good for unit test. And IMHO, ftrace unit test should be within the kernel tree. > > > On Tue, 05 Aug 2014 02:45:44 + > Masami Hiramatsu wrote: > >> Hi, >> >> I'd like to introduce a collection of testcases for ftrace to >> avoid regressions. >> >> For a long time, we've tried to stabilize and extend ftrace >> tracing infrastructure. This small test framework is a kind of >> stabilizing work for ftrace. For the first step, this series >> just introduces a few basic testcases. However, it is easy to >> add additional tests. I'd like to ask you, ftrace developers, >> to add tests for your features to ensure it will not be broken >> by future works. >> >> ftracetest is a tiny bash script so that anyone can easily >> understand what it does. I think it is better to share and >> discuss this tests before growing it. >> >> - Is it enough to support bash script? (of course you can >>invoke other commands from the script) >> - What's the good naming method of testcases? >> - Is any dependency check required? >> >> BTW, I decided to put this under tools/testing/ftrace instead >> of tools/testing/selftests/, because all tests requires root >> privilege. It will be one of discussion points. Anyway, >> it is easy to integrate this to the selftests. > > I agree. I think having its own directory is a good idea. Lets see what > other people think. Actually, current sefltests provides just a space, not minimal functions, like log management, test statistics, etc. which ftracetest has. And I doubt that Make-based test framework is good for providing such functions. I think it is also another option to generalize the ftracetest script for selftests :) > When I get time, I'll see if I can start a branch > that pulls this in and start adding my own tests on top of it. I look forward to see your tests :) Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi: Initialize variable to prevent uninitialized warning
While compiling we see the following waring
drivers/spi/spi-bfin5xx.c: In function 'bfin_spi_pump_transfers':
drivers/spi/spi-bfin5xx.c:695:6: warning: 'cr_width' may be used uninitialized
in this function [-Wuninitialized]
Initialize it to prevent the above warning
Signed-off-by: Nick Krause
---
drivers/spi/spi-bfin5xx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi-bfin5xx.c b/drivers/spi/spi-bfin5xx.c
index ebf720b..f268bf4 100644
--- a/drivers/spi/spi-bfin5xx.c
+++ b/drivers/spi/spi-bfin5xx.c
@@ -559,7 +559,7 @@ static void bfin_spi_pump_transfers(unsigned long data)
struct spi_transfer *previous = NULL;
struct bfin_spi_slave_data *chip = NULL;
unsigned int bits_per_word;
- u16 cr, cr_width, dma_width, dma_config;
+ u16 cr, cr_width = 0, dma_width, dma_config;
u32 tranf_success = 1;
u8 full_duplex = 0;
@@ -648,7 +648,6 @@ static void bfin_spi_pump_transfers(unsigned long data)
} else if (bits_per_word == 8) {
drv_data->n_bytes = bits_per_word/8;
drv_data->len = transfer->len;
- cr_width = 0;
drv_data->ops = _bfin_spi_transfer_ops_u8;
}
cr = bfin_read(_data->regs->ctl) & ~(BIT_CTL_TIMOD |
BIT_CTL_WORDSIZE);
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: rtl8192u: fix sparse warnings in r8192U_core.c
Fix the following sparse warnings:
drivers/staging/rtl8192u/r8192U_core.c:670:6: warning: symbol 'dump_eprom'
was not declared. Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:1556:14: warning: symbol
'txqueue2outpipe' was not declared. Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:4876:5: warning: symbol
'GetRxPacketShiftBytes819xUsb' was not declared. Should it be static?
Signed-off-by: A Raghavendra Rao
---
drivers/staging/rtl8192u/r8192U_core.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 7640386..6ad767a 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -667,12 +667,14 @@ static void tx_timeout(struct net_device *dev)
/* this is only for debug */
-void dump_eprom(struct net_device *dev)
+#ifdef DEBUG_EPROM
+static void dump_eprom(struct net_device *dev)
{
int i;
for (i = 0; i < 63; i++)
RT_TRACE(COMP_EPROM, "EEPROM addr %x : %x", i, eprom_read(dev,
i));
}
+#endif
void rtl8192_update_msr(struct net_device *dev)
{
@@ -1553,7 +1555,9 @@ u16 N_DBPSOfRate(u16 DataRate)
return N_DBPS;
}
-unsigned int txqueue2outpipe(struct r8192_priv *priv, unsigned int tx_queue)
+#ifndef USE_ONE_PIPE
+static unsigned int txqueue2outpipe(struct r8192_priv *priv,
+ unsigned int tx_queue)
{
if (tx_queue >= 9) {
RT_TRACE(COMP_ERR, "%s():Unknown queue ID!!!\n", __func__);
@@ -1561,6 +1565,7 @@ unsigned int txqueue2outpipe(struct r8192_priv *priv,
unsigned int tx_queue)
}
return priv->txqueue_to_outpipemap[tx_queue];
}
+#endif
short rtl819xU_tx_cmd(struct net_device *dev, struct sk_buff *skb)
{
@@ -4873,17 +4878,18 @@ static void query_rxdesc_status(struct sk_buff *skb,
}
-u32 GetRxPacketShiftBytes819xUsb(struct ieee80211_rx_stats *Status, bool
bIsRxAggrSubframe)
-{
#ifdef USB_RX_AGGREGATION_SUPPORT
+static u32 GetRxPacketShiftBytes819xUsb(struct ieee80211_rx_stats *Status,
+ bool bIsRxAggrSubframe)
+{
if (bIsRxAggrSubframe)
return (sizeof(rx_desc_819x_usb) + Status->RxDrvInfoSize
+ Status->RxBufShift + 8);
else
-#endif
return (sizeof(rx_desc_819x_usb) + Status->RxDrvInfoSize
+ Status->RxBufShift);
}
+#endif
static void rtl8192_rx_nomal(struct sk_buff *skb)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/gpio: Check return value to silence warning
On Thu, Aug 7, 2014 at 1:40 PM, Nick Krause wrote: > Check for return value to fix the following error > > drivers/gpio/gpio-sch311x.c: In function 'sch311x_gpio_probe': > drivers/gpio/gpio-sch311x.c:286:18: warning: ignoring return value of > 'gpiochip_remove', declared with attribute warn_unused_result > [-Wunused-result] > > in the context we do not need to check but checking makes compiler happy. > With help from kernelnewbies. This patch is not needed: the warn_unused_result has been removed for 3.17, and gpiochip_remove will be changed to return void soon anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers/gpio: Check return value to silence warning
Check for return value to fix the following error drivers/gpio/gpio-sch311x.c: In function 'sch311x_gpio_probe': drivers/gpio/gpio-sch311x.c:286:18: warning: ignoring return value of 'gpiochip_remove', declared with attribute warn_unused_result [-Wunused-result] in the context we do not need to check but checking makes compiler happy. With help from kernelnewbies. Signed-off-by: Nick Krause --- drivers/gpio/gpio-sch311x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-sch311x.c b/drivers/gpio/gpio-sch311x.c index f942b80..af35e99 100644 --- a/drivers/gpio/gpio-sch311x.c +++ b/drivers/gpio/gpio-sch311x.c @@ -283,7 +283,7 @@ exit_err: release_region(pdata->runtime_reg + GP1, 6); /* release already registered chips */ for (--i; i >= 0; i--) - gpiochip_remove(>blocks[i].chip); + WARN_ON(gpiochip_remove(>blocks[i].chip)); return err; } -- 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: [alsa-devel] [PATCH V1 1/2] ASoC: fsl: esai: refine esai for tdm support
About the title, please follow the old pattern:
ASoC: fsl_esai: Refine
You can get the history from 'git log --oneline sound/soc/fsl/fsl_esai.c'
On Wed, Aug 06, 2014 at 06:23:03PM +0800, Shengjiu Wang wrote:
> Add parameter for slots, and caculate the number of TX/RX pins and bclk with
> slots. Then driver will be compatible with slots > 2 in TDM mode.
Hmm...although I totally understand what the patch's exactly improving,
I suggest to describe more so that other people can get a quick idea
even without looking at the code, like what the original driver lacks
or what's the problem of the original design, how this patch fulfills
this feature and why some change have to be done, those change in the
header file for example.
> Signed-off-by: Shengjiu Wang
> ---
> sound/soc/fsl/fsl_esai.c | 10 +++---
> sound/soc/fsl/fsl_esai.h |8
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index 72d154e..89aa531 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -56,6 +56,7 @@ struct fsl_esai {
> struct clk *fsysclk;
> u32 fifo_depth;
> u32 slot_width;
> + u32 slots;
> u32 hck_rate[2];
> u32 sck_rate[2];
> bool hck_dir[2];
Please append a description for the new member to the existing comments
above the structure define.
> @@ -363,6 +364,7 @@ static int fsl_esai_set_dai_tdm_slot(struct snd_soc_dai
> *dai, u32 tx_mask,
> ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(rx_mask));
>
> esai_priv->slot_width = slot_width;
> + esai_priv->slots = slots;
I prefer not to add indentation here, even thought this doesn't hurt.
Just...If there's going to be a subsequent patch adding a new member
assignment whose name's longer than slot_width, the style'll be broken
as well. For example:
esai_priv->slot_width = slot_width;
esai_priv->slots = slots;
esai_priv->slot_samplebit = slots;
The indentation for the 'slots' will look abnormal.
>
> return 0;
> }
> @@ -510,10 +512,11 @@ static int fsl_esai_hw_params(struct snd_pcm_substream
> *substream,
> bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> u32 width = snd_pcm_format_width(params_format(params));
> u32 channels = params_channels(params);
> + u32 pin = DIV_ROUND_UP(channels, esai_priv->slots);
This may cause a 'Division by zero' here. The 'slots' is only assigned
in set_dai_tdm_slot(). As default, a machine driver who does not call
set_dai_tdm_slot() will get a zero slot. We must give 'slots' a default
value (2 for example) somewhere during initialization.
And another personal suggestion -- using name 'pins' might be better.
Thank you Shengjiu,
Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Hibernate: check unsafe page should not in e820 reserved region
Hi experts,
On Mon, Aug 04, 2014 at 11:23:21PM +0800, Lee, Chun-Yi wrote:
> When the machine doesn't well handle the e820 persistent when hibernate
> resuming, then it may causes page fault when writing image to snapshot
> buffer:
>
> [ 17.929495] BUG: unable to handle kernel paging request at 880069d4f000
> [ 17.933469] IP: [] load_image_lzo+0x810/0xe40
> [ 17.933469] PGD 2194067 PUD 77067 PMD 2197067 PTE 0
> [ 17.933469] Oops: 0002 [#1] SMP
> ...
>
> The 880069d4f000 page is in e820 reserved region of resume boot
> kernel:
>
> [0.00] BIOS-e820: [mem 0x69d4f000-0x69e12fff] reserved
> ...
> [0.00] PM: Registered nosave memory: [mem 0x69d4f000-0x69e12fff]
>
> So snapshot.c mark the pfn to forbidden pages map. But, this
> page is also in the memory bitmap in snapshot image because it's an
> original page used by image kernel, so it will also mark as an
> unsafe(free) page in prepare_image().
>
> That means the page in e820 when resuming mark as "forbidden" and
> "free", it causes get_buffer() treat it as an allocated unsafe page.
> Then snapshot_write_next() return this page to load_image, load_image
> writing content to this address, but this page didn't really allocated
> . So, we got page fault.
>
> Although the root cause is from BIOS, I think aggressive check and
> significant message in kernel will better then a page fault for
> issue tracking, especially when serial console unavailable.
>
> This patch adds code in mark_unsafe_pages() for check does free pages in
> nosave region. If so, then it print message and return fault to stop whole
> S4 resume process:
>
> [8.166004] PM: Image loading progress: 0%
> [8.658717] PM: 0x6796c000 in e820 nosave region: [mem
> 0x6796c000-0x6796cfff]
> [8.918737] PM: Read 2511940 kbytes in 1.04 seconds (2415.32 MB/s)
> [8.926633] PM: Error -14 resuming
> [8.933534] PM: Failed to load hibernation image, recovering.
>
> v2:
> + removed empty check of nosave_regions list.
> + fixed the typo of "region" in code for error message and patch comment.
>
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Takashi Iwai
> Acked-by: Pavel Machek
> Signed-off-by: Lee, Chun-Yi
I discussed with Vojtech Pavlik for this patch, he raised a situation is:
Maybe e820 changed but image kernel original pages do not fall into new e820
region.
Then the hibernate will recovery success, but later kernel drivers may got
problem
when accessing memory.
My idea is hashing the start/end pfn of each nosave region sequentially, put
this
nosave region digest to hibernate header then compare e820 digest in
check_header()
when hibernate resuming.
I am developing patch, then we don't need check unsafe page should not in
unsave(e820)
regions.
Thanks a lot!
Joey Lee
> ---
> kernel/power/snapshot.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index 4fc5c32..c4b8093 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -954,6 +954,25 @@ static void mark_nosave_pages(struct memory_bitmap *bm)
> }
> }
>
> +static bool is_nosave_page(unsigned long pfn)
> +{
> + struct nosave_region *region;
> +
> + list_for_each_entry(region, _regions, list) {
> + if (pfn >= region->start_pfn && pfn < region->end_pfn) {
> + pr_err("PM: %#010llx in e820 nosave region: "
> +"[mem %#010llx-%#010llx]\n",
> +(unsigned long long) pfn << PAGE_SHIFT,
> +(unsigned long long) region->start_pfn <<
> PAGE_SHIFT,
> +((unsigned long long) region->end_pfn <<
> PAGE_SHIFT)
> + - 1);
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> /**
> * create_basic_memory_bitmaps - create bitmaps needed for marking page
> * frames that should not be saved and free page frames. The pointers
> @@ -2015,7 +2034,7 @@ static int mark_unsafe_pages(struct memory_bitmap *bm)
> do {
> pfn = memory_bm_next_pfn(bm);
> if (likely(pfn != BM_END_OF_MAP)) {
> - if (likely(pfn_valid(pfn)))
> + if (likely(pfn_valid(pfn)) && !is_nosave_page(pfn))
> swsusp_set_page_free(pfn_to_page(pfn));
> else
> return -EFAULT;
> --
> 1.8.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] pwm: rockchip: Added to support for RK3288 SoC
Doug,
在 2014年08月07日 11:46, Doug Anderson 写道:
Caesar,
On Wed, Aug 6, 2014 at 8:37 PM, caesar wrote:
Doug,
在 2014年08月07日 11:26, Doug Anderson 写道:
caesar,
On Wed, Aug 6, 2014 at 8:23 PM, caesar wrote:
在 2014年08月07日 10:16, Doug Anderson 写道:
Caesar,
On Wed, Aug 6, 2014 at 6:27 PM, caesar
wrote:
Doug,
在 2014年08月07日 06:46, Doug Anderson 写道:
Caesar,
On Thu, Jul 24, 2014 at 3:21 AM, Caesar Wang
wrote:
+static const struct rockchip_pwm_data pwm_data_v1 = {
+ .regs.duty = PWM_HRC,
+ .regs.period = PWM_LRC,
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
+ .prescaler = PRESCALER,
+ .set_enable = rockchip_pwm_set_enable_v1,
+};
+
+static const struct rockchip_pwm_data pwm_data_v2 = {
+ .regs.duty = PWM_LRC,
+ .regs.period = PWM_HRC,
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
+ .prescaler = PRESCALER-1,
+ .set_enable = rockchip_pwm_set_enable_v2,
+};
+
+static const struct rockchip_pwm_data pwm_data_vop = {
+ .regs.duty = PWM_LRC,
+ .regs.period = PWM_HRC,
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
Did you really mean to flip CTRL and CNTR here? If so, that's super
confusing and deserves a comment. AKA, I think the above should not
be:
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
...but should be
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
If you didn't mean to flip CTRL and CNTR here, then just get rid of
pwm_data_vop and refer to pwm_data_v2. In fact, I'd suggest that you
totally remove the "rockchip,vop-pwm" since there's nothing different
between "rockchip,rk3288-pwm" and "rockchip,vop-pwm".
Sorry,I think it's no problem. the "rockchip,rk3288-pwm" and
"rockchip,vop-pwm" are seperate PWM controllers.
They are just different registers address between CNTR and CTRL .
OK, I looked up in the TRM. Right, the CNTR and CTRL are flipped on
the vop. So I think that the only change you need is to add:
#define PWM_VOP_CTRL 0x00
#define PWM_VOP_CNTR 0x0c
...then use these new #defines for the vop structure.
As you have the code written right now it's very confusing. The new
#defines will fix this.
yeah, I think they can be used in the same context.
I will fix it in patch v5 if it is really need.
I think you should fix this, but if Thierry doesn't think so then it's
really his decision.
I remember In patch v2 [1],Thierry suggests me to fix it so if I have no to
get wrong.
[1]: https://lkml.org/lkml/2014/7/21/113
I think Thierry might not have realized that they were flipped...
-Doug
Maybe you are right.
I will sent patch v5 fix the about tomorrow if it has no other problems.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] trivial for 3.17
On Wed, Aug 6, 2014 at 2:37 AM, Jiri Kosina wrote: > > You are going to get two conflicts super-easy to resolve: > > - arch/arm/mach-msm/Kconfig removal of unused MSM_SCM config value > conflicts with addition of MSM_TIMER to the same spot; resolution is to > keep MSM_TIMER and remove MSM_SCM That's not right. Both MSM_TIMER and MSM_SCM went away. > - Documentation/laptops/hpfall.c conflict easy to resolve by Looks correct. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cris: bug: add unreachable() to silence warnings
Cris BUG() have warnings like
drivers/memstick/core/ms_block.c:677:1: warning: control reaches end of
non-void function
drivers/memstick/core/ms_block.c:720:1: warning: control reaches end of
non-void function
drivers/memstick/core/ms_block.c:654:1: warning: control reaches end of
non-void function
drivers/memstick/core/ms_block.c:465:1: warning: control reaches end of
non-void function
drivers/memstick/core/mspro_block.c:663:1: warning: control reaches end of
non-void function
Other BUG() implementations
have added unreachable() at end becuase of which I guess
it does not showthese errors. We can silence them using unreachable().
Signed-off-by: Nick Krause
---
arch/cris/include/arch-v10/arch/bug.h | 5 -
arch/cris/include/arch-v32/arch/bug.h | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/cris/include/arch-v10/arch/bug.h
b/arch/cris/include/arch-v10/arch/bug.h
index 3485d6b..40e65ad 100644
--- a/arch/cris/include/arch-v10/arch/bug.h
+++ b/arch/cris/include/arch-v10/arch/bug.h
@@ -43,12 +43,15 @@ struct bug_frame {
* not be used like this with newer versions of gcc.
*/
#define BUG() \
+do { \
__asm__ __volatile__ ("clear.d [" __stringify(BUG_MAGIC) "]\n\t"\
"movu.w " __stringify(__LINE__) ",$r0\n\t"\
"jump 0f\n\t" \
".section .rodata\n" \
"0:\t.string \"" __FILE__ "\"\n\t"\
- ".previous")
+ ".previous"); \
+ unreachable(); \
+} while (0)
#endif
#else
diff --git a/arch/cris/include/arch-v32/arch/bug.h
b/arch/cris/include/arch-v32/arch/bug.h
index 0f211e1..55350a3 100644
--- a/arch/cris/include/arch-v32/arch/bug.h
+++ b/arch/cris/include/arch-v32/arch/bug.h
@@ -10,6 +10,7 @@
* All other stuff is done out-of-band with exception handlers.
*/
#define BUG() \
+do { \
__asm__ __volatile__ ("0: break 14\n\t" \
".section .fixup,\"ax\"\n"\
"1:\n\t" \
@@ -21,7 +22,9 @@
".section __ex_table,\"a\"\n\t" \
".dword 0b, 1b\n\t" \
".previous\n\t" \
- : : "ri" (__FILE__), "i" (__LINE__))
+ : : "ri" (__FILE__), "i" (__LINE__)); \
+ unreachable();
+} while (0)
#else
#define BUG() __asm__ __volatile__ ("break 14\n\t")
#endif
--
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 v4 2/2] pwm: rockchip: Added to support for RK3288 SoC
Caesar,
On Wed, Aug 6, 2014 at 8:37 PM, caesar wrote:
> Doug,
>
> 在 2014年08月07日 11:26, Doug Anderson 写道:
>
>> caesar,
>>
>> On Wed, Aug 6, 2014 at 8:23 PM, caesar wrote:
>>>
>>> 在 2014年08月07日 10:16, Doug Anderson 写道:
>>>
Caesar,
On Wed, Aug 6, 2014 at 6:27 PM, caesar
wrote:
>
> Doug,
>
> 在 2014年08月07日 06:46, Doug Anderson 写道:
>
>> Caesar,
>>
>> On Thu, Jul 24, 2014 at 3:21 AM, Caesar Wang
>>
>> wrote:
>>>
>>> +static const struct rockchip_pwm_data pwm_data_v1 = {
>>> + .regs.duty = PWM_HRC,
>>> + .regs.period = PWM_LRC,
>>> + .regs.cntr = PWM_CNTR,
>>> + .regs.ctrl = PWM_CTRL,
>>> + .prescaler = PRESCALER,
>>> + .set_enable = rockchip_pwm_set_enable_v1,
>>> +};
>>> +
>>> +static const struct rockchip_pwm_data pwm_data_v2 = {
>>> + .regs.duty = PWM_LRC,
>>> + .regs.period = PWM_HRC,
>>> + .regs.cntr = PWM_CNTR,
>>> + .regs.ctrl = PWM_CTRL,
>>> + .prescaler = PRESCALER-1,
>>> + .set_enable = rockchip_pwm_set_enable_v2,
>>> +};
>>> +
>>> +static const struct rockchip_pwm_data pwm_data_vop = {
>>> + .regs.duty = PWM_LRC,
>>> + .regs.period = PWM_HRC,
>>> + .regs.cntr = PWM_CTRL,
>>> + .regs.ctrl = PWM_CNTR,
>>
>> Did you really mean to flip CTRL and CNTR here? If so, that's super
>> confusing and deserves a comment. AKA, I think the above should not
>> be:
>>
>> + .regs.cntr = PWM_CTRL,
>> + .regs.ctrl = PWM_CNTR,
>>
>> ...but should be
>>
>> + .regs.cntr = PWM_CNTR,
>> + .regs.ctrl = PWM_CTRL,
>>
>> If you didn't mean to flip CTRL and CNTR here, then just get rid of
>> pwm_data_vop and refer to pwm_data_v2. In fact, I'd suggest that you
>> totally remove the "rockchip,vop-pwm" since there's nothing different
>> between "rockchip,rk3288-pwm" and "rockchip,vop-pwm".
>
>
> Sorry,I think it's no problem. the "rockchip,rk3288-pwm" and
> "rockchip,vop-pwm" are seperate PWM controllers.
> They are just different registers address between CNTR and CTRL .
OK, I looked up in the TRM. Right, the CNTR and CTRL are flipped on
the vop. So I think that the only change you need is to add:
#define PWM_VOP_CTRL 0x00
#define PWM_VOP_CNTR 0x0c
...then use these new #defines for the vop structure.
As you have the code written right now it's very confusing. The new
#defines will fix this.
>>> yeah, I think they can be used in the same context.
>>>
>>> I will fix it in patch v5 if it is really need.
>>
>> I think you should fix this, but if Thierry doesn't think so then it's
>> really his decision.
>
> I remember In patch v2 [1],Thierry suggests me to fix it so if I have no to
> get wrong.
>
> [1]: https://lkml.org/lkml/2014/7/21/113
I think Thierry might not have realized that they were flipped...
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: Fix warnings about right shift count
Fix warnings like the following using upper_32_bits(), discussed after mail with someone on kernelnewbies arch/powerpc/boot/addnote.c:183:3: warning: right shift count >= width of type arch/powerpc/boot/addnote.c:188:3: warning: right shift count >= width of type arch/powerpc/boot/addnote.c:206:3: warning: right shift count >= width of type arch/powerpc/boot/addnote.c:211:3: warning: right shift count >= width of type Signed-off-by: Nick Krause --- arch/powerpc/boot/addnote.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/addnote.c b/arch/powerpc/boot/addnote.c index 9d9f6f3..4611c12 100644 --- a/arch/powerpc/boot/addnote.c +++ b/arch/powerpc/boot/addnote.c @@ -72,7 +72,7 @@ static int e_class = ELFCLASS32; #define PUT_16BE(off, v)(buf[off] = ((v) >> 8) & 0xff, \ buf[(off) + 1] = (v) & 0xff) #define PUT_32BE(off, v)(PUT_16BE((off), (v) >> 16L), PUT_16BE((off) + 2, (v))) -#define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \ +#define PUT_64BE(off, v)((PUT_32BE((off), upper_32_bits(v)), \ PUT_32BE((off) + 4, (v #define GET_16LE(off) ((buf[off]) + (buf[(off)+1] << 8)) @@ -82,7 +82,8 @@ static int e_class = ELFCLASS32; #define PUT_16LE(off, v) (buf[off] = (v) & 0xff, \ buf[(off) + 1] = ((v) >> 8) & 0xff) #define PUT_32LE(off, v) (PUT_16LE((off), (v)), PUT_16LE((off) + 2, (v) >> 16L)) -#define PUT_64LE(off, v) (PUT_32LE((off), (v)), PUT_32LE((off) + 4, (v) >> 32L)) +#define PUT_64LE(off, v) (PUT_32LE((off), (v)), PUT_32LE((off) + 4, \ + upper_32_bits(v))) #define GET_16(off)(e_data == ELFDATA2MSB ? GET_16BE(off) : GET_16LE(off)) #define GET_32(off)(e_data == ELFDATA2MSB ? GET_32BE(off) : GET_32LE(off)) -- 2.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB: atmel_usba_udc: fix it to deal with final DMA channel
As, the interrupt for DMA is counted from 1, so need to checked
the USBA_NR_DMAS, in old way, it only check (USBA_NR_DMAS - 1),
so fix it.
Reported-by: Max Liao
Signed-off-by: Bo Shen
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 906e65f..c9fe67e 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1661,7 +1661,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (dma_status) {
int i;
- for (i = 1; i < USBA_NR_DMAS; i++)
+ for (i = 1; i <= USBA_NR_DMAS; i++)
if (dma_status & (1 << i))
usba_dma_irq(udc, >usba_ep[i]);
}
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] pwm: rockchip: Added to support for RK3288 SoC
Doug,
在 2014年08月07日 11:26, Doug Anderson 写道:
caesar,
On Wed, Aug 6, 2014 at 8:23 PM, caesar wrote:
在 2014年08月07日 10:16, Doug Anderson 写道:
Caesar,
On Wed, Aug 6, 2014 at 6:27 PM, caesar wrote:
Doug,
在 2014年08月07日 06:46, Doug Anderson 写道:
Caesar,
On Thu, Jul 24, 2014 at 3:21 AM, Caesar Wang
wrote:
+static const struct rockchip_pwm_data pwm_data_v1 = {
+ .regs.duty = PWM_HRC,
+ .regs.period = PWM_LRC,
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
+ .prescaler = PRESCALER,
+ .set_enable = rockchip_pwm_set_enable_v1,
+};
+
+static const struct rockchip_pwm_data pwm_data_v2 = {
+ .regs.duty = PWM_LRC,
+ .regs.period = PWM_HRC,
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
+ .prescaler = PRESCALER-1,
+ .set_enable = rockchip_pwm_set_enable_v2,
+};
+
+static const struct rockchip_pwm_data pwm_data_vop = {
+ .regs.duty = PWM_LRC,
+ .regs.period = PWM_HRC,
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
Did you really mean to flip CTRL and CNTR here? If so, that's super
confusing and deserves a comment. AKA, I think the above should not
be:
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
...but should be
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
If you didn't mean to flip CTRL and CNTR here, then just get rid of
pwm_data_vop and refer to pwm_data_v2. In fact, I'd suggest that you
totally remove the "rockchip,vop-pwm" since there's nothing different
between "rockchip,rk3288-pwm" and "rockchip,vop-pwm".
Sorry,I think it's no problem. the "rockchip,rk3288-pwm" and
"rockchip,vop-pwm" are seperate PWM controllers.
They are just different registers address between CNTR and CTRL .
OK, I looked up in the TRM. Right, the CNTR and CTRL are flipped on
the vop. So I think that the only change you need is to add:
#define PWM_VOP_CTRL 0x00
#define PWM_VOP_CNTR 0x0c
...then use these new #defines for the vop structure.
As you have the code written right now it's very confusing. The new
#defines will fix this.
yeah, I think they can be used in the same context.
I will fix it in patch v5 if it is really need.
I think you should fix this, but if Thierry doesn't think so then it's
really his decision.
I remember In patch v2 [1],Thierry suggests me to fix it so if I have no
to get wrong.
[1]: https://lkml.org/lkml/2014/7/21/113
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting
Kever, On Tue, Aug 5, 2014 at 6:01 PM, Kever Yang wrote: > According to the "dr_mode", the otg controller can work as > device role and host role. Some boards always want to use host mode > and some other boards want to use gadget mode. We use the dts setting > to set dwc2's mode, rather than fixing it to whatever hardware says. > > Signed-off-by: Kever Yang > Acked-by: Paul Zimmerman > --- > > Changes in v4: > - From Doug's suggestion: > -- remove dr_mode init from Kconfig code > -- change the commit meesage > > Changes in v3: > - fix the odd spacing in dwc2_hsotg struct > - From Jingoo's suggestion: > change the commit message > - add dr_mode init from Kconfig > > Changes in v2: > - put spaces around '+' operator > - expand the comment for dr_mode > - handle dr_mode is USB_DR_MODE_OTG > > drivers/usb/dwc2/core.c | 18 ++ > drivers/usb/dwc2/core.h | 5 + > drivers/usb/dwc2/platform.c | 4 > 3 files changed, 27 insertions(+) I don't know the driver well enough to feel like I can add my Reviewed-by tag, but since you've already got an Ack from Paul it doesn't matter much. ...FWIW I'm happy with the current state of the code now. :) -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] pwm: rockchip: Added to support for RK3288 SoC
caesar,
On Wed, Aug 6, 2014 at 8:23 PM, caesar wrote:
>
> 在 2014年08月07日 10:16, Doug Anderson 写道:
>
>> Caesar,
>>
>> On Wed, Aug 6, 2014 at 6:27 PM, caesar wrote:
>>>
>>> Doug,
>>>
>>> 在 2014年08月07日 06:46, Doug Anderson 写道:
>>>
Caesar,
On Thu, Jul 24, 2014 at 3:21 AM, Caesar Wang
wrote:
>
> +static const struct rockchip_pwm_data pwm_data_v1 = {
> + .regs.duty = PWM_HRC,
> + .regs.period = PWM_LRC,
> + .regs.cntr = PWM_CNTR,
> + .regs.ctrl = PWM_CTRL,
> + .prescaler = PRESCALER,
> + .set_enable = rockchip_pwm_set_enable_v1,
> +};
> +
> +static const struct rockchip_pwm_data pwm_data_v2 = {
> + .regs.duty = PWM_LRC,
> + .regs.period = PWM_HRC,
> + .regs.cntr = PWM_CNTR,
> + .regs.ctrl = PWM_CTRL,
> + .prescaler = PRESCALER-1,
> + .set_enable = rockchip_pwm_set_enable_v2,
> +};
> +
> +static const struct rockchip_pwm_data pwm_data_vop = {
> + .regs.duty = PWM_LRC,
> + .regs.period = PWM_HRC,
> + .regs.cntr = PWM_CTRL,
> + .regs.ctrl = PWM_CNTR,
Did you really mean to flip CTRL and CNTR here? If so, that's super
confusing and deserves a comment. AKA, I think the above should not
be:
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
...but should be
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
If you didn't mean to flip CTRL and CNTR here, then just get rid of
pwm_data_vop and refer to pwm_data_v2. In fact, I'd suggest that you
totally remove the "rockchip,vop-pwm" since there's nothing different
between "rockchip,rk3288-pwm" and "rockchip,vop-pwm".
>>>
>>>
>>> Sorry,I think it's no problem. the "rockchip,rk3288-pwm" and
>>> "rockchip,vop-pwm" are seperate PWM controllers.
>>> They are just different registers address between CNTR and CTRL .
>>
>> OK, I looked up in the TRM. Right, the CNTR and CTRL are flipped on
>> the vop. So I think that the only change you need is to add:
>>
>> #define PWM_VOP_CTRL 0x00
>> #define PWM_VOP_CNTR 0x0c
>>
>> ...then use these new #defines for the vop structure.
>>
>>
>> As you have the code written right now it's very confusing. The new
>> #defines will fix this.
>>
> yeah, I think they can be used in the same context.
>
> I will fix it in patch v5 if it is really need.
I think you should fix this, but if Thierry doesn't think so then it's
really his decision.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] pwm: rockchip: Added to support for RK3288 SoC
在 2014年08月07日 10:16, Doug Anderson 写道:
Caesar,
On Wed, Aug 6, 2014 at 6:27 PM, caesar wrote:
Doug,
在 2014年08月07日 06:46, Doug Anderson 写道:
Caesar,
On Thu, Jul 24, 2014 at 3:21 AM, Caesar Wang
wrote:
+static const struct rockchip_pwm_data pwm_data_v1 = {
+ .regs.duty = PWM_HRC,
+ .regs.period = PWM_LRC,
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
+ .prescaler = PRESCALER,
+ .set_enable = rockchip_pwm_set_enable_v1,
+};
+
+static const struct rockchip_pwm_data pwm_data_v2 = {
+ .regs.duty = PWM_LRC,
+ .regs.period = PWM_HRC,
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
+ .prescaler = PRESCALER-1,
+ .set_enable = rockchip_pwm_set_enable_v2,
+};
+
+static const struct rockchip_pwm_data pwm_data_vop = {
+ .regs.duty = PWM_LRC,
+ .regs.period = PWM_HRC,
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
Did you really mean to flip CTRL and CNTR here? If so, that's super
confusing and deserves a comment. AKA, I think the above should not
be:
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
...but should be
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
If you didn't mean to flip CTRL and CNTR here, then just get rid of
pwm_data_vop and refer to pwm_data_v2. In fact, I'd suggest that you
totally remove the "rockchip,vop-pwm" since there's nothing different
between "rockchip,rk3288-pwm" and "rockchip,vop-pwm".
Sorry,I think it's no problem. the "rockchip,rk3288-pwm" and
"rockchip,vop-pwm" are seperate PWM controllers.
They are just different registers address between CNTR and CTRL .
OK, I looked up in the TRM. Right, the CNTR and CTRL are flipped on
the vop. So I think that the only change you need is to add:
#define PWM_VOP_CTRL 0x00
#define PWM_VOP_CNTR 0x0c
...then use these new #defines for the vop structure.
As you have the code written right now it's very confusing. The new
#defines will fix this.
yeah, I think they can be used in the same context.
I will fix it in patch v5 if it is really need.
Have you validated Thierry's suggestion to allow you to access your
memory range?
Yes,we have solve it in lcdc driver.
The Mark Yao have the submission in [0].
[0]: https://lkml.org/lkml/2014/8/4/20
Excellent! Then we should be able to land after you fix the above.
-Doug
OK,Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the modules tree
Hi Rusty,
After merging the modules tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/powernv/opal-elog.c:85:28: error: macro "__ATTR_RO"
passed 2 arguments, but takes just 1
__ATTR_RO(id, elog_id_show);
^
arch/powerpc/platforms/powernv/opal-elog.c:85:2: error: '__ATTR_RO' undeclared
here (not in a function)
__ATTR_RO(id, elog_id_show);
^
arch/powerpc/platforms/powernv/opal-elog.c:87:32: error: macro "__ATTR_RO"
passed 2 arguments, but takes just 1
__ATTR_RO(type, elog_type_show);
^
And it went down hill from there ...
Caused by commit ba987e9b8ab1
("arch/powerpc/platforms/powernv/opal-elog.c: fix world-writable sysfs
files").
I have used the modules tree from next-20140725 again for today.
There is still the error in
arch/powerpc/platforms/powernv/opal-dump.c ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[GIT] Networking
This fixes the most immediate fallout from yesterday's networking merge. 1) sock_tx_timestamp() must not clear the passed in tx_flags, but rather add to them. Fix from Eric Dumazet. 2) The hyperv driver sendbuf region increase needs to be decreased slightly to handle older backends. From KY Srinivasan. 3) Fix RCU lockdep splats in netlink diag after recent hashing changes, from Thomas Graf. 4) The new IPV6_FLOWLABEL was given a socket option number that overlapped with an existing IP6 tables one, breaking ip6_tables. Fixed by Pablo Neira Ayuso. Please pull, thanks a lot! The following changes since commit 85417aef44fc58b08773117ceb1bc6ca5684e973: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide (2014-08-06 09:42:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 6c8f7e70837468da4e658080d4448930fb597e1b: netlink: hold nl_sock_hash_lock during diag dump (2014-08-06 19:17:44 -0700) Dmitry Popov (1): tcp: md5: check md5 signature without socket lock Eric Dumazet (1): net-timestamp: sock_tx_timestamp() fix Francois Romieu (1): net: fix USB network driver config option. Hans Wennborg (1): vmxnet3: fix decimal printf format specifiers prefixed with 0x Hariprasad Shenai (1): cxgb4: Fix for SR-IOV VF initialization KY Srinivasan (1): hyperv: Adjust the size of sendbuf region to support ws2008r2 Pablo Neira (1): net: reallocate new socket option number for IPV6_AUTOFLOWLABEL Thomas Graf (1): netlink: hold nl_sock_hash_lock during diag dump Willem de Bruijn (1): net-timestamp: cumulative tcp timestamping fixes drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 7 +++ drivers/net/hyperv/hyperv_net.h | 2 +- drivers/net/usb/Kconfig | 4 ++-- drivers/net/vmxnet3/vmxnet3_drv.c | 2 +- drivers/net/wireless/Kconfig| 1 + include/net/sock.h | 6 -- include/uapi/linux/in6.h| 2 +- net/ipv4/tcp.c | 12 +++- net/ipv4/tcp_ipv4.c | 36 +--- net/ipv4/tcp_offload.c | 8 net/ipv6/tcp_ipv6.c | 25 +++-- net/netlink/af_netlink.c| 1 + net/netlink/af_netlink.h| 1 + net/netlink/diag.c | 3 +++ net/socket.c| 20 +--- 15 files changed, 86 insertions(+), 44 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2 2/3] ARM: clk-imx6q: Add missing lvds and anaclk clock to the clock tree
Hi Stash, Shawn
Do we have such API for exclusive clock? Or Do you have example for these
exclusive clocks?
Best regards
Wang shengjiu
-Original Message-
From: Lucas Stach [mailto:l.st...@pengutronix.de]
Sent: Wednesday, August 06, 2014 10:42 PM
To: Wang Shengjiu-B02247
Cc: Guo Shawn-R65073; ker...@pengutronix.de; li...@arm.linux.org.uk;
robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Chen Guangyu-B42378;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 2/3] ARM: clk-imx6q: Add missing lvds and anaclk clock
to the clock tree
Am Mittwoch, den 06.08.2014, 16:35 +0800 schrieb Shengjiu Wang:
> anaclk1 and anaclk2 is the clock source for lvds1_in and lvds2_in.
> lvds1_in and lvds2_in can be used to provide external clock source to
> the internal pll, such as pll4_audio and pll5_video.
> pll4_audio and pll5_video can have multiple source, not only "osc", so
> add them.
>
> Signed-off-by: Nicolin Chen
> Signed-off-by: Shengjiu Wang
> ---
> arch/arm/mach-imx/clk-imx6q.c | 12 ++--
> include/dt-bindings/clock/imx6qdl-clock.h |8 +++-
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c
> b/arch/arm/mach-imx/clk-imx6q.c index 1d6dd59..330aad3 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -73,6 +73,7 @@ static const char *lvds_sels[] = {
> "pll4_audio", "pll5_video", "pll8_mlb", "enet_ref",
> "pcie_ref_125m", "sata_ref_100m",
> };
> +static const char *pll_av_sels[] = { "osc", "lvds1_in", "lvds2_in",
> +"dummy", };
>
> static struct clk *clk[IMX6QDL_CLK_END]; static struct
> clk_onecell_data clk_data; @@ -119,6 +120,9 @@ static void __init
> imx6q_clocks_init(struct device_node *ccm_node)
> clk[IMX6QDL_CLK_CKIL] = imx_obtain_fixed_clock("ckil", 0);
> clk[IMX6QDL_CLK_CKIH] = imx_obtain_fixed_clock("ckih1", 0);
> clk[IMX6QDL_CLK_OSC] = imx_obtain_fixed_clock("osc", 0);
> + /* Clock source from external clock via ANACLK1/2 PADs */
> + clk[IMX6QDL_CLK_ANACLK1] = imx_obtain_fixed_clock("anaclk1", 0);
> + clk[IMX6QDL_CLK_ANACLK2] = imx_obtain_fixed_clock("anaclk2", 0);
>
> np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
> base = of_iomap(np, 0);
> @@ -136,8 +140,8 @@ static void __init imx6q_clocks_init(struct device_node
> *ccm_node)
> clk[IMX6QDL_CLK_PLL1_SYS] = imx_clk_pllv3(IMX_PLLV3_SYS,
> "pll1_sys", "osc", base,0x7f);
> clk[IMX6QDL_CLK_PLL2_BUS] = imx_clk_pllv3(IMX_PLLV3_GENERIC,
> "pll2_bus", "osc", base + 0x30, 0x1);
> clk[IMX6QDL_CLK_PLL3_USB_OTG] = imx_clk_pllv3(IMX_PLLV3_USB,
> "pll3_usb_otg", "osc", base + 0x10, 0x3);
> - clk[IMX6QDL_CLK_PLL4_AUDIO]= imx_clk_pllv3(IMX_PLLV3_AV,
> "pll4_audio", "osc", base + 0x70, 0x7f);
> - clk[IMX6QDL_CLK_PLL5_VIDEO]= imx_clk_pllv3(IMX_PLLV3_AV,
> "pll5_video", "osc", base + 0xa0, 0x7f);
> + clk[IMX6QDL_CLK_PLL4_AUDIO]= imx_clk_pllv3(IMX_PLLV3_AV,
> "pll4_audio", "pll4_sel", base + 0x70, 0x7f);
> + clk[IMX6QDL_CLK_PLL5_VIDEO]= imx_clk_pllv3(IMX_PLLV3_AV,
> "pll5_video", "pll5_sel", base + 0xa0, 0x7f);
> clk[IMX6QDL_CLK_PLL6_ENET] = imx_clk_pllv3(IMX_PLLV3_ENET,
> "pll6_enet","osc", base + 0xe0, 0x3);
> clk[IMX6QDL_CLK_PLL7_USB_HOST] = imx_clk_pllv3(IMX_PLLV3_USB,
> "pll7_usb_host","osc", base + 0x20, 0x3);
>
> @@ -169,6 +173,8 @@ static void __init imx6q_clocks_init(struct
> device_node *ccm_node)
>
> clk[IMX6QDL_CLK_LVDS1_SEL] = imx_clk_mux("lvds1_sel", base + 0x160, 0,
> 5, lvds_sels, ARRAY_SIZE(lvds_sels));
> clk[IMX6QDL_CLK_LVDS2_SEL] = imx_clk_mux("lvds2_sel", base + 0x160,
> 5, 5, lvds_sels, ARRAY_SIZE(lvds_sels));
> + clk[IMX6QDL_CLK_PLL4_SEL] = imx_clk_mux("pll4_sel", base + 0x70, 14,
> 2, pll_av_sels, ARRAY_SIZE(pll_av_sels));
> + clk[IMX6QDL_CLK_PLL5_SEL] = imx_clk_mux("pll5_sel", base + 0xa0,
> +14, 2, pll_av_sels, ARRAY_SIZE(pll_av_sels));
>
> /*
>* lvds1_gate and lvds2_gate are pseudo-gates. Both can be @@
> -178,6 +184,8 @@ static void __init imx6q_clocks_init(struct device_node
> *ccm_node)
>*/
> clk[IMX6QDL_CLK_LVDS1_GATE] = imx_clk_gate("lvds1_gate", "lvds1_sel",
> base + 0x160, 10);
> clk[IMX6QDL_CLK_LVDS2_GATE] = imx_clk_gate("lvds2_gate",
> "lvds2_sel", base + 0x160, 11);
> + clk[IMX6QDL_CLK_LVDS1_IN] = imx_clk_gate("lvds1_in", "anaclk1", base +
> 0x160, 12);
> + clk[IMX6QDL_CLK_LVDS2_IN] = imx_clk_gate("lvds2_in", "anaclk2", base
> ++ 0x160, 13);
>
I think we need something more clever here. With both lvds in and out modeled
as a clock gate it is possible for the user to enable both at the same time.
The reference manual on the contrary states that both states are mutually
exclusive: "Do not enable
Re: [PATCH v4 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting
On 8/6/14, 5:57 PM, Paul Zimmerman wrote:
>> From: diand...@google.com [mailto:diand...@google.com] On Behalf Of Doug
>> Anderson
>> Sent: Wednesday, August 06, 2014 3:25 PM
>>
>> On Tue, Aug 5, 2014 at 6:01 PM, Kever Yang wrote:
>>> According to the "dr_mode", the otg controller can work as
>>> device role and host role. Some boards always want to use host mode
>>> and some other boards want to use gadget mode. We use the dts setting
>>> to set dwc2's mode, rather than fixing it to whatever hardware says.
>>>
>>> Signed-off-by: Kever Yang
>>> Acked-by: Paul Zimmerman
>>> ---
>>>
>>> Changes in v4:
>>> - From Doug's suggestion:
>>> -- remove dr_mode init from Kconfig code
>>> -- change the commit meesage
>>>
>>> Changes in v3:
>>> - fix the odd spacing in dwc2_hsotg struct
>>> - From Jingoo's suggestion:
>>> change the commit message
>>> - add dr_mode init from Kconfig
>>>
>>> Changes in v2:
>>> - put spaces around '+' operator
>>> - expand the comment for dr_mode
>>> - handle dr_mode is USB_DR_MODE_OTG
>>>
>>> drivers/usb/dwc2/core.c | 18 ++
>>> drivers/usb/dwc2/core.h | 5 +
>>> drivers/usb/dwc2/platform.c | 4
>>> 3 files changed, 27 insertions(+)
>> I think this patch still makes sense even though we don't have a
>> combined driver yet. Perhaps Paul or Dihn can confirm.
> Yes, it should be fine.
>
>> We could potentially do something based on KConfig (like you did in
>> patch set #3), but it wouldn't really make sense to do that until
>> after Dihn's work lands.
>>
>>
>>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>>> index 27d2c9b..738bec2 100644
>>> --- a/drivers/usb/dwc2/core.c
>>> +++ b/drivers/usb/dwc2/core.c
>>> @@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>>> {
>>> u32 greset;
>>> int count = 0;
>>> + u32 gusbcfg;
>>>
>>> dev_vdbg(hsotg->dev, "%s()\n", __func__);
>>>
>>> @@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>>> }
>>> } while (greset & GRSTCTL_CSFTRST);
>>>
>>> + if (hsotg->dr_mode == USB_DR_MODE_HOST) {
>>> + gusbcfg = readl(hsotg->regs + GUSBCFG);
>>> + gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
>>> + gusbcfg |= GUSBCFG_FORCEHOSTMODE;
>>> + writel(gusbcfg, hsotg->regs + GUSBCFG);
>>> + } else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
>>> + gusbcfg = readl(hsotg->regs + GUSBCFG);
>>> + gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
>>> + gusbcfg |= GUSBCFG_FORCEDEVMODE;
>>> + writel(gusbcfg, hsotg->regs + GUSBCFG);
>>> + } else if (hsotg->dr_mode == USB_DR_MODE_OTG) {
>>> + gusbcfg = readl(hsotg->regs + GUSBCFG);
>>> + gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
>>> + gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
>>> + writel(gusbcfg, hsotg->regs + GUSBCFG);
>> I think the third case here won't be too useful until the combined
>> driver, but it shouldn't hurt, right?
> Right. For the existing drivers, it shouldn't change anything, since
> nothing currently sets dr_mode. And with Kever's other patches, it
> forces host mode on the Rockchip platform, which is all that is required
> for now, if I understand correctly.
>
I managed to test this patch on the SOCFPGA platform. So
Tested-by: Dinh Nguyen
Thanks,
DInh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] ARM: imx6q: Add the clock route from external OSC to ESAI clock
Ok, thanks.
-Original Message-
From: Shawn Guo [mailto:shawn@freescale.com]
Sent: Thursday, August 07, 2014 11:12 AM
To: Wang Shengjiu-B02247
Cc: ker...@pengutronix.de; li...@arm.linux.org.uk; robh...@kernel.org;
pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
ga...@codeaurora.org; Chen Guangyu-B42378;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 3/3] ARM: imx6q: Add the clock route from external OSC
to ESAI clock
On Wed, Aug 06, 2014 at 04:35:15PM +0800, Shengjiu Wang wrote:
> This patch mainly adds the clock route from external 24.576MHz OSC to
> internal ESAI clock via analog clock2 PADs on the SoC and pll4 so that
> ESAI can get an entirely synchronous clock source against CS42888.
>
> [ 1, We found if using pll4 to generate a 24.576MHz from inernal 24.0MHz OSC,
> we would get noise during the audio playback via ESAI->CS42888 even though
> this generated clock's rate is equal to the external one statistically. It
> might be resulted from the tiny difference between two clock source, which
> might be crucial to the sensitive CODEC we use -- CS42888.
>
> 2, Ideally, we should use bypass mode for pll4 since we only need to get
> the raw rate (24.576MHz) while currently bypass mode in clk-pllv3.c isn't
> supported. After bypass mode implement, then we can refine this
> patch.]
I meant we should implement bypass mode first. I will give it a try.
Shawn
>
> Expected result:
>
> anaclk2 0 124576000
>lvds2_in 0 124576000
> pll4_sel 0 124576000
> pll4_audio 0 1786432000
> pll4_post_div 0 1786432000
>pll4_audio_div 0 1786432000
> esai_sel 0 1786432000
> esai_pred0 198304000
> esai_podf 0 124576000
>esai_extal 0 124576000
>
> Signed-off-by: Nicolin Chen
> Signed-off-by: Shengjiu Wang
> ---
> arch/arm/mach-imx/clk-imx6q.c |5 +
> arch/arm/mach-imx/mach-imx6q.c | 28
> 2 files changed, 33 insertions(+)
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c
> b/arch/arm/mach-imx/clk-imx6q.c index 330aad3..29151cb 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -414,6 +414,10 @@ static void __init imx6q_clocks_init(struct device_node
> *ccm_node)
> of_clk_add_provider(np, of_clk_src_onecell_get, _data);
>
> clk_register_clkdev(clk[IMX6QDL_CLK_ENET_REF], "enet_ref", NULL);
> + clk_register_clkdev(clk[IMX6QDL_CLK_PLL4_AUDIO_DIV], "pll4_audio_div",
> NULL);
> + clk_register_clkdev(clk[IMX6QDL_CLK_PLL4_SEL], "pll4_sel", NULL);
> + clk_register_clkdev(clk[IMX6QDL_CLK_LVDS2_IN], "lvds2_in", NULL);
> + clk_register_clkdev(clk[IMX6QDL_CLK_ESAI_EXTAL], "esai_extal",
> +NULL);
>
> if ((imx_get_soc_revision() != IMX_CHIP_REVISION_1_0) ||
> cpu_is_imx6dl()) {
> @@ -457,6 +461,7 @@ static void __init imx6q_clocks_init(struct
> device_node *ccm_node)
>
> /* Audio-related clocks configuration */
> clk_set_parent(clk[IMX6QDL_CLK_SPDIF_SEL],
> clk[IMX6QDL_CLK_PLL3_PFD3_454M]);
> + clk_set_parent(clk[IMX6QDL_CLK_ESAI_SEL],
> +clk[IMX6QDL_CLK_PLL4_AUDIO_DIV]);
>
> /* All existing boards with PCIe use LVDS1 */
> if (IS_ENABLED(CONFIG_PCI_IMX6))
> diff --git a/arch/arm/mach-imx/mach-imx6q.c
> b/arch/arm/mach-imx/mach-imx6q.c index d51c6e9..ea24a96 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -362,6 +362,28 @@ put_node:
> of_node_put(np);
> }
>
> +#define ESAI_AUDIO_MCLK 24576000
> +
> +static void __init imx6q_audio_lvds2_init(void) {
> +struct clk *pll4_sel, *lvds2_in, *pll4_audio_div,
> +*esai_extal;
> +
> +pll4_audio_div = clk_get_sys(NULL, "pll4_audio_div");
> +pll4_sel = clk_get_sys(NULL, "pll4_sel");
> +lvds2_in = clk_get_sys(NULL, "lvds2_in");
> +esai_extal = clk_get_sys(NULL, "esai_extal");
> +if (IS_ERR(pll4_audio_div) || IS_ERR(pll4_sel) ||
> +IS_ERR(lvds2_in) || IS_ERR(esai_extal))
> +return;
> +
> +if (clk_get_rate(lvds2_in) != ESAI_AUDIO_MCLK)
> +return;
> +
> +clk_set_parent(pll4_sel, lvds2_in);
> +clk_set_rate(pll4_audio_div, 786432000);
> +clk_set_rate(esai_extal, ESAI_AUDIO_MCLK); }
> +
> static struct platform_device imx6q_cpufreq_pdev = {
> .name = "imx6q-cpufreq",
> };
> @@ -379,6 +401,12 @@ static void __init imx6q_init_late(void)
> imx6q_opp_init();
> platform_device_register(_cpufreq_pdev);
> }
> +
> + if
Re: [PATCH V2 3/3] ARM: imx6q: Add the clock route from external OSC to ESAI clock
On Wed, Aug 06, 2014 at 04:35:15PM +0800, Shengjiu Wang wrote:
> This patch mainly adds the clock route from external 24.576MHz OSC to internal
> ESAI clock via analog clock2 PADs on the SoC and pll4 so that ESAI can get an
> entirely synchronous clock source against CS42888.
>
> [ 1, We found if using pll4 to generate a 24.576MHz from inernal 24.0MHz OSC,
> we would get noise during the audio playback via ESAI->CS42888 even though
> this generated clock's rate is equal to the external one statistically. It
> might be resulted from the tiny difference between two clock source, which
> might be crucial to the sensitive CODEC we use -- CS42888.
>
> 2, Ideally, we should use bypass mode for pll4 since we only need to get
> the raw rate (24.576MHz) while currently bypass mode in clk-pllv3.c isn't
> supported. After bypass mode implement, then we can refine this patch.]
I meant we should implement bypass mode first. I will give it a try.
Shawn
>
> Expected result:
>
> anaclk2 0 124576000
>lvds2_in 0 124576000
> pll4_sel 0 124576000
> pll4_audio 0 1786432000
> pll4_post_div 0 1786432000
>pll4_audio_div 0 1786432000
> esai_sel 0 1786432000
> esai_pred0 198304000
> esai_podf 0 124576000
>esai_extal 0 124576000
>
> Signed-off-by: Nicolin Chen
> Signed-off-by: Shengjiu Wang
> ---
> arch/arm/mach-imx/clk-imx6q.c |5 +
> arch/arm/mach-imx/mach-imx6q.c | 28
> 2 files changed, 33 insertions(+)
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index 330aad3..29151cb 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -414,6 +414,10 @@ static void __init imx6q_clocks_init(struct device_node
> *ccm_node)
> of_clk_add_provider(np, of_clk_src_onecell_get, _data);
>
> clk_register_clkdev(clk[IMX6QDL_CLK_ENET_REF], "enet_ref", NULL);
> + clk_register_clkdev(clk[IMX6QDL_CLK_PLL4_AUDIO_DIV], "pll4_audio_div",
> NULL);
> + clk_register_clkdev(clk[IMX6QDL_CLK_PLL4_SEL], "pll4_sel", NULL);
> + clk_register_clkdev(clk[IMX6QDL_CLK_LVDS2_IN], "lvds2_in", NULL);
> + clk_register_clkdev(clk[IMX6QDL_CLK_ESAI_EXTAL], "esai_extal", NULL);
>
> if ((imx_get_soc_revision() != IMX_CHIP_REVISION_1_0) ||
> cpu_is_imx6dl()) {
> @@ -457,6 +461,7 @@ static void __init imx6q_clocks_init(struct device_node
> *ccm_node)
>
> /* Audio-related clocks configuration */
> clk_set_parent(clk[IMX6QDL_CLK_SPDIF_SEL],
> clk[IMX6QDL_CLK_PLL3_PFD3_454M]);
> + clk_set_parent(clk[IMX6QDL_CLK_ESAI_SEL],
> clk[IMX6QDL_CLK_PLL4_AUDIO_DIV]);
>
> /* All existing boards with PCIe use LVDS1 */
> if (IS_ENABLED(CONFIG_PCI_IMX6))
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index d51c6e9..ea24a96 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -362,6 +362,28 @@ put_node:
> of_node_put(np);
> }
>
> +#define ESAI_AUDIO_MCLK 24576000
> +
> +static void __init imx6q_audio_lvds2_init(void)
> +{
> +struct clk *pll4_sel, *lvds2_in, *pll4_audio_div, *esai_extal;
> +
> +pll4_audio_div = clk_get_sys(NULL, "pll4_audio_div");
> +pll4_sel = clk_get_sys(NULL, "pll4_sel");
> +lvds2_in = clk_get_sys(NULL, "lvds2_in");
> +esai_extal = clk_get_sys(NULL, "esai_extal");
> +if (IS_ERR(pll4_audio_div) || IS_ERR(pll4_sel) ||
> +IS_ERR(lvds2_in) || IS_ERR(esai_extal))
> +return;
> +
> +if (clk_get_rate(lvds2_in) != ESAI_AUDIO_MCLK)
> +return;
> +
> +clk_set_parent(pll4_sel, lvds2_in);
> +clk_set_rate(pll4_audio_div, 786432000);
> +clk_set_rate(esai_extal, ESAI_AUDIO_MCLK);
> +}
> +
> static struct platform_device imx6q_cpufreq_pdev = {
> .name = "imx6q-cpufreq",
> };
> @@ -379,6 +401,12 @@ static void __init imx6q_init_late(void)
> imx6q_opp_init();
> platform_device_register(_cpufreq_pdev);
> }
> +
> + if (of_machine_is_compatible("fsl,imx6q-sabreauto")
> + || of_machine_is_compatible("fsl,imx6dl-sabreauto")) {
> + imx6q_audio_lvds2_init();
> + }
> +
> }
>
> static void __init imx6q_map_io(void)
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8192u: fix sparse warnings in r8192U_core.c
On Wed, Aug 06, 2014 at 02:14:16PM +0530, A Raghavendra Rao wrote: > Fix the following sparse warnings: > drivers/staging/rtl8192u/r8192U_core.c:670:6: warning: symbol 'dump_eprom' > was not declared. Should it be static? > drivers/staging/rtl8192u/r8192U_core.c:1556:14: warning: symbol > 'txqueue2outpipe' was not declared. Should it be static? > drivers/staging/rtl8192u/r8192U_core.c:4876:5: warning: symbol > 'GetRxPacketShiftBytes819xUsb' was not declared. Should it be static? > > Signed-off-by: A Raghavendra Rao > --- > drivers/staging/rtl8192u/r8192U_core.c |8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) This patch causes warnings to be added to the build, don't do that :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: testing result of loop-aio patchset on ext3
On 2014/7/21 10:34, Rui Xiang wrote: > On 2014/7/18 17:10, Lukáš Czerner wrote: >> On Wed, 16 Jul 2014, Rui Xiang wrote: >> >>> Date: Wed, 16 Jul 2014 17:28:10 +0800 >>> From: Rui Xiang >>> To: Lukáš Czerner >>> Cc: Dave Kleikamp , linux-e...@vger.kernel.org, >>> linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org, >>> Li Zefan >>> Subject: Re: testing result of loop-aio patchset on ext3 >>> >>> On 2014/7/16 15:58, Lukáš Czerner wrote: On Wed, 16 Jul 2014, Rui Xiang wrote: > Date: Wed, 16 Jul 2014 11:54:24 +0800 > From: Rui Xiang > To: Lukáš Czerner > Cc: Dave Kleikamp , linux-e...@vger.kernel.org, > linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org, > Li Zefan > Subject: Re: testing result of loop-aio patchset on ext3 > > On 2014/7/14 17:51, Lukáš Czerner wrote: >> On Mon, 14 Jul 2014, Rui Xiang wrote: >> >>> Date: Mon, 14 Jul 2014 17:34:38 +0800 >>> From: Rui Xiang >>> To: Dave Kleikamp , linux-e...@vger.kernel.org >>> Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org, >>> Li Zefan >>> Subject: testing result of loop-aio patchset on ext3 >>> >>> Hi Dave, >>> >>> We export a container image file as a block device via loop device, but >>> we >>> found it's very easy that the container rootfs gets corrupted due to >>> power >>> loss. >>> >>> Your early version of loop-aio patchset said the patchset can make loop >>> mounted filesystems recoverable(lkml.org/lkml/2012/3/30/317), but we >>> found >>> it doesn't help. >>> >>> Both the guest fs and host fs are ext3. >>> >>> The loop-aio patchset is from: >>> git://github.com/kleikamp/linux-shaggy.git aio_loop >>> >>> Steps: >>> 1. dd a 10G image, mkfs.ext3, >>> # dd if=/dev/zero of=./raw_image bs=1M count=1 >>> # echo y | mkfs.ext3 raw_image >>> >>> 2. losetup a loop device, mount at ./test_dir >>> # losetup /dev/loop1 raw_image >>> # mount /dev/loop1 ./test_dir >>> >>> 3. copy fs_mark into test_dir and run >>> # ./fs_mark -d ./tmp/ -s 10240 -n 80 >>> >>> 4. during runing fs_mark, make systerm reboot indirectly. >>> # echo b > /proc/sysrq-trigger >>> >>> After systerm booted up, sometimes fsck reported raw_image fs has been >>> damaged. >>> >>> # fsck.ext3 -n raw_image >>> e2fsck 1.41.9 (22-Aug-2009) >>> Warning: skipping journal recovery because doing a read-only filesystem >>> check. >>> raw_image contains a file system with errors, check forced. >>> Pass 1: Checking inodes, blocks, and sizes >>> Pass 2: Checking directory structure >>> Pass 3: Checking directory connectivity >>> Pass 4: Checking reference counts >>> Pass 5: Checking group summary information >>> Free blocks count wrong (2481348, counted=2480577). >>> Fix? no >>> Free inodes count wrong (640837, counted=640835). >>> Fix? no >>> raw_image: ** WARNING: Filesystem still has errors ** >>> raw_image: 11/640848 files (0.0% non-contiguous), 78652/256 blocks >> >> It's not damaged, this is expected result if you're using old >> e2fsprogs which still treats this as an error. >> >> It's not an error because we only update superblock summary at >> unmount time so with unclean shutdown it's likely that it does not >> match the reality, but e2fsck can and will easily fix that for you. >> >> Please try e2fsprogs v1.42.3 or newer. >> > > Hi Lukas, > > I updated e2fsprogs to v1.42.3, and user the newer fsck.ext3 to check > raw_image. > Exactly, the result seemed normal. Now I can see that there are much more problems than before, that's weird. Sorry for not making this clear, but for this kind of reproducers please use the most recent e2fsprogs. Also , what is the kernel version you're using in this test ? >>> >>> I use the most recent e2fsprogs 1.42.11 to check, and the error info is >>> same as >>> result fscked by v1.42.3. It seems that shouldn't be the reason. >>> >>> Otherwise, the kernel version in this test is stable 3.4. >> >> In that case, this is a problem somewhere else. I'll try to >> reproduce and see what I can see. >> >> I assume you're not able to reproduce this on a real device ? >> > > Yes, it only exits on a loop device in my test. > > Otherwise, There was another case in this test: > > I fsck the err image with "-n", the result contains 7 issues. > > # fsck.ext3 -n image1 > Warning: skipping journal recovery because doing a read-only filesystem check. > image1 has been mounted 36 times without being checked, check forced. > Pass 1: Checking inodes, blocks, and sizes > *Inode 16407, i_size is 643005, should be 647168. Fix? no > *Inode 16407, i_blocks is 1264, should be 1272. Fix? no > *Inode 409941,
[PATCH] HID:hid-logitech: Prevent possibility of infinite loop when using /sys interface
If the device data is not accessible for some reason, returning 0 will cause
the call to be
continuously called again as none of the string has been 'consumed'.
---
drivers/hid/hid-lg4ff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index cc2bd20..7835717 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -451,13 +451,13 @@ static ssize_t lg4ff_range_store(struct device *dev,
struct device_attribute *at
drv_data = hid_get_drvdata(hid);
if (!drv_data) {
hid_err(hid, "Private driver data not found!\n");
- return 0;
+ return -EINVAL;
}
entry = drv_data->device_props;
if (!entry) {
hid_err(hid, "Device properties not found!\n");
- return 0;
+ return -EINVAL;
}
if (range == 0)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: testing result of loop-aio patchset on ext3
On 2014/7/21 10:34, Rui Xiang wrote: > On 2014/7/18 17:10, Lukáš Czerner wrote: >> On Wed, 16 Jul 2014, Rui Xiang wrote: >> >>> Date: Wed, 16 Jul 2014 17:28:10 +0800 >>> From: Rui Xiang >>> To: Lukáš Czerner >>> Cc: Dave Kleikamp , linux-e...@vger.kernel.org, >>> linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org, >>> Li Zefan >>> Subject: Re: testing result of loop-aio patchset on ext3 >>> >>> On 2014/7/16 15:58, Lukáš Czerner wrote: On Wed, 16 Jul 2014, Rui Xiang wrote: > Date: Wed, 16 Jul 2014 11:54:24 +0800 > From: Rui Xiang > To: Lukáš Czerner > Cc: Dave Kleikamp , linux-e...@vger.kernel.org, > linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org, > Li Zefan > Subject: Re: testing result of loop-aio patchset on ext3 > > On 2014/7/14 17:51, Lukáš Czerner wrote: >> On Mon, 14 Jul 2014, Rui Xiang wrote: >> >>> Date: Mon, 14 Jul 2014 17:34:38 +0800 >>> From: Rui Xiang >>> To: Dave Kleikamp , linux-e...@vger.kernel.org >>> Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org, >>> Li Zefan >>> Subject: testing result of loop-aio patchset on ext3 >>> >>> Hi Dave, >>> >>> We export a container image file as a block device via loop device, but >>> we >>> found it's very easy that the container rootfs gets corrupted due to >>> power >>> loss. >>> >>> Your early version of loop-aio patchset said the patchset can make loop >>> mounted filesystems recoverable(lkml.org/lkml/2012/3/30/317), but we >>> found >>> it doesn't help. >>> >>> Both the guest fs and host fs are ext3. >>> >>> The loop-aio patchset is from: >>> git://github.com/kleikamp/linux-shaggy.git aio_loop >>> >>> Steps: >>> 1. dd a 10G image, mkfs.ext3, >>> # dd if=/dev/zero of=./raw_image bs=1M count=1 >>> # echo y | mkfs.ext3 raw_image >>> >>> 2. losetup a loop device, mount at ./test_dir >>> # losetup /dev/loop1 raw_image >>> # mount /dev/loop1 ./test_dir >>> >>> 3. copy fs_mark into test_dir and run >>> # ./fs_mark -d ./tmp/ -s 10240 -n 80 >>> >>> 4. during runing fs_mark, make systerm reboot indirectly. >>> # echo b > /proc/sysrq-trigger >>> >>> After systerm booted up, sometimes fsck reported raw_image fs has been >>> damaged. >>> >>> # fsck.ext3 -n raw_image >>> e2fsck 1.41.9 (22-Aug-2009) >>> Warning: skipping journal recovery because doing a read-only filesystem >>> check. >>> raw_image contains a file system with errors, check forced. >>> Pass 1: Checking inodes, blocks, and sizes >>> Pass 2: Checking directory structure >>> Pass 3: Checking directory connectivity >>> Pass 4: Checking reference counts >>> Pass 5: Checking group summary information >>> Free blocks count wrong (2481348, counted=2480577). >>> Fix? no >>> Free inodes count wrong (640837, counted=640835). >>> Fix? no >>> raw_image: ** WARNING: Filesystem still has errors ** >>> raw_image: 11/640848 files (0.0% non-contiguous), 78652/256 blocks >> >> It's not damaged, this is expected result if you're using old >> e2fsprogs which still treats this as an error. >> >> It's not an error because we only update superblock summary at >> unmount time so with unclean shutdown it's likely that it does not >> match the reality, but e2fsck can and will easily fix that for you. >> >> Please try e2fsprogs v1.42.3 or newer. >> > > Hi Lukas, > > I updated e2fsprogs to v1.42.3, and user the newer fsck.ext3 to check > raw_image. > Exactly, the result seemed normal. Now I can see that there are much more problems than before, that's weird. Sorry for not making this clear, but for this kind of reproducers please use the most recent e2fsprogs. Also , what is the kernel version you're using in this test ? >>> >>> I use the most recent e2fsprogs 1.42.11 to check, and the error info is >>> same as >>> result fscked by v1.42.3. It seems that shouldn't be the reason. >>> >>> Otherwise, the kernel version in this test is stable 3.4. >> >> In that case, this is a problem somewhere else. I'll try to >> reproduce and see what I can see. >> >> I assume you're not able to reproduce this on a real device ? >> > > Yes, it only exits on a loop device in my test. > > Otherwise, There was another case in this test: > > I fsck the err image with "-n", the result contains 7 issues. > > # fsck.ext3 -n image1 > Warning: skipping journal recovery because doing a read-only filesystem check. > image1 has been mounted 36 times without being checked, check forced. > Pass 1: Checking inodes, blocks, and sizes > *Inode 16407, i_size is 643005, should be 647168. Fix? no > *Inode 16407, i_blocks is 1264, should be 1272. Fix? no > *Inode 409941,
[PATCH 1/1] ACPI: Check if acpi_device->handler is NULL when ACPI_HOTPLUG_MEMORY is not configured.
When ACPI_HOTPLUG_MEMORY is not configured, memory_device_handler.attach is not
set.
And in acpi_scan_attach_handler(), the acpi_device->handler will not be
initialized.
In acpi_scan_hot_remove(), it doesn't check if acpi_device->handler is NULL.
If we do memory hot-remove without ACPI_HOTPLUG_MEMORY configured, the kernel
will panic.
[ 250.304538] BUG: unable to handle kernel NULL pointer dereference at
0088
[ 250.304960] IP: [] acpi_device_hotplug+0x1d7/0x4c4
[ 250.305120] PGD 0
[ 250.305120] Oops: [#1] SMP
[ 250.305120] Modules linked in: sd_mod(E) sr_mod(E) cdrom(E) crc_t10dif(E)
crct10dif_common(E) ata_piix(E) libata(E)
[ 250.305120] CPU: 0 PID: 41 Comm: kworker/u2:1 Tainted: GE
3.16.0-rc7--3.16-rc7-tangchen+ #20
[ 250.305120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[ 250.305120] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 250.305120] task: 8800182436c0 ti: 880018254000 task.ti:
880018254000
[ 250.305120] RIP: 0010:[] []
acpi_device_hotplug+0x1d7/0x4c4
[ 250.305120] RSP: :880018257da8 EFLAGS: 0246
[ 250.305120] RAX: RBX: 88001cd8d800 RCX:
[ 250.305120] RDX: RSI: 88001e40e6f8 RDI: 0246
[ 250.305120] RBP: 880018257df0 R08: 0096 R09: 11a0
[ 250.305120] R10: 63735f6970636120 R11: 725f746f685f6e61 R12: 0003
[ 250.305120] R13: 88001cc1c400 R14: 88001e062028 R15: 0040
[ 250.305120] FS: () GS:88001e40()
knlGS:
[ 250.305120] CS: 0010 DS: ES: CR0: 8005003b
[ 250.305120] CR2: 0088 CR3: 1a9a2000 CR4: 06f0
[ 250.305120] DR0: DR1: DR2:
[ 250.305120] DR3: DR6: DR7:
[ 250.305120] Stack:
[ 250.305120] 523cab58 88001cd8d9f8 88001852d480
523cab58
[ 250.305120] 88001852d480 880018221e40 88001cc1c400
88001cce2d00
[ 250.305120] 0040 880018257e08 813dc31d
88001852d480
[ 250.305120] Call Trace:
[ 250.305120] [] acpi_hotplug_work_fn+0x1e/0x29
[ 250.305120] [] process_one_work+0x17b/0x460
[ 250.305120] [] worker_thread+0x11d/0x5b0
[ 250.305120] [] ? rescuer_thread+0x3a0/0x3a0
[ 250.305120] [] kthread+0xe1/0x100
[ 250.305120] [] ? kthread_create_on_node+0x1a0/0x1a0
[ 250.305120] [] ret_from_fork+0x7c/0xb0
[ 250.305120] [] ? kthread_create_on_node+0x1a0/0x1a0
This patch fixes this problem by checking if acpi_device->handler is NULL in
acpi_scan_hot_remove().
Signed-off-by: Tang Chen
---
drivers/acpi/scan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index f775fa0..aae0ce0 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -351,7 +351,8 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
unsigned long long sta;
acpi_status status;
- if (device->handler->hotplug.demand_offline && !acpi_force_hot_remove) {
+ if (device->handler && device->handler->hotplug.demand_offline
+ && !acpi_force_hot_remove) {
if (!acpi_scan_is_offline(device, true))
return -EBUSY;
} else {
--
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/
[no subject]
Hello,i have a business proposal worth a sum of Twenty Million Six Hundred Thousand Great British Pounds.if interested please response through this email:markcarnetdept...@outlook.com. Regard Mark Carney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] arm: use generic fixmap.h
On 8/6/2014 12:32 PM, Kees Cook wrote:
> From: Mark Salter
>
> ARM is different from other architectures in that fixmap pages are indexed
> with a positive offset from FIXADDR_START. Other architectures index with
> a negative offset from FIXADDR_TOP. In order to use the generic fixmap.h
> definitions, this patch redefines FIXADDR_TOP to be inclusive of the
> useable range. That is, FIXADDR_TOP is the virtual address of the topmost
> fixed page. The newly defined FIXADDR_END is the first virtual address
> past the fixed mappings.
>
> Signed-off-by: Mark Salter
> Reviewed-by: Doug Anderson
> [update for "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"]
> Signed-off-by: Kees Cook
> ---
> arch/arm/include/asm/fixmap.h | 27 +--
> arch/arm/mm/init.c| 2 +-
> 2 files changed, 10 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index 74124b0d0d79..190142d174ee 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -2,27 +2,18 @@
> #define _ASM_FIXMAP_H
>
> #define FIXADDR_START0xffc0UL
> -#define FIXADDR_TOP 0xffe0UL
> -#define FIXADDR_SIZE (FIXADDR_TOP - FIXADDR_START)
> +#define FIXADDR_END 0xffe0UL
> +#define FIXADDR_TOP (FIXADDR_END - PAGE_SIZE)
> +#define FIXADDR_SIZE (FIXADDR_END - FIXADDR_START)
>
> #define FIX_KMAP_NR_PTES (FIXADDR_SIZE >> PAGE_SHIFT)
>
> -#define __fix_to_virt(x) (FIXADDR_START + ((x) << PAGE_SHIFT))
> -#define __virt_to_fix(x) (((x) - FIXADDR_START) >> PAGE_SHIFT)
> +enum fixed_addresses {
> + FIX_KMAP_BEGIN,
> + FIX_KMAP_END = FIX_KMAP_NR_PTES - 1,
> + __end_of_fixed_addresses
> +};
>
> -extern void __this_fixmap_does_not_exist(void);
> -
> -static inline unsigned long fix_to_virt(const unsigned int idx)
> -{
> - if (idx >= FIX_KMAP_NR_PTES)
> - __this_fixmap_does_not_exist();
> - return __fix_to_virt(idx);
> -}
> -
> -static inline unsigned int virt_to_fix(const unsigned long vaddr)
> -{
> - BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
> - return __virt_to_fix(vaddr);
> -}
> +#include
>
> #endif
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 659c75d808dc..ad82c05bfc3a 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -570,7 +570,7 @@ void __init mem_init(void)
> MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
> MLK(ITCM_OFFSET, (unsigned long) itcm_end),
> #endif
> - MLK(FIXADDR_START, FIXADDR_TOP),
> + MLK(FIXADDR_START, FIXADDR_END),
> MLM(VMALLOC_START, VMALLOC_END),
> MLM(PAGE_OFFSET, (unsigned long)high_memory),
> #ifdef CONFIG_HIGHMEM
>
I'm working off of a 3.14 kernel and with this backported
kmap_atomic does not actually map properly for me. This was
my quick fix (not sure if we should be using __set_fixmap?). Or did
I fail at backportery?
-8<-
>From ea11b54704aa0a311ab3d05fd70072679bfe1a0b Mon Sep 17 00:00:00 2001
From: Laura Abbott
Date: Wed, 6 Aug 2014 19:20:46 -0700
Subject: [PATCH] arm: Get proper pte for fixmaps
The generic fixmap.h gets indexes from high to low instead
of low to high so the fixmap idx does not correspond to
the array entry in fixmap_page_table. Get the proper pte
to update.
Signed-off-by: Laura Abbott
---
arch/arm/mm/highmem.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index bedca3a..7f08e64 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -22,14 +22,18 @@
static inline void set_fixmap_pte(int idx, pte_t pte)
{
unsigned long vaddr = __fix_to_virt(idx);
- set_pte_ext(fixmap_page_table + idx, pte, 0);
+ pte_t *ppte = pte_offset_kernel(pmd_off_k(FIXADDR_START), vaddr);
+
+ set_pte_ext(ppte, pte, 0);
local_flush_tlb_kernel_page(vaddr);
}
static inline pte_t get_fixmap_pte(unsigned long vaddr)
{
unsigned long idx = __virt_to_fix(vaddr);
- return *(fixmap_page_table + idx);
+ pte_t *ppte = pte_offset_kernel(pmd_off_k(FIXADDR_START), vaddr);
+
+ return *ppte;
}
void *kmap(struct page *page)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [media] V4L: Add camera pan/tilt speed controls
On Thu, Aug 7, 2014 at 12:10 AM, Vincent Palatin wrote: > > On Sun, Aug 3, 2014 at 10:52 PM, Pawel Osciak wrote: > > This looks good to me in general (with one comment below). I don't think we > > can easily implement current V4L2 pan and tilt controls that are for > > movement by a specified amount in terms of UVC pan/tilt speed controls, > > which only let us set speed and direction... > > > > On Wed, Jul 9, 2014 at 8:49 AM, Vincent Palatin > > wrote: > >> > >> The V4L2_CID_PAN_SPEED and V4L2_CID_TILT_SPEED controls allow to move the > >> camera by setting its rotation speed around its axis. > >> > >> Signed-off-by: Vincent Palatin > >> > >> --- > >> Documentation/DocBook/media/v4l/compat.xml | 10 ++ > >> Documentation/DocBook/media/v4l/controls.xml | 21 + > >> drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++ > >> include/uapi/linux/v4l2-controls.h | 2 ++ > >> 4 files changed, 35 insertions(+) > >> > >> diff --git a/Documentation/DocBook/media/v4l/compat.xml > >> b/Documentation/DocBook/media/v4l/compat.xml > >> index eee6f0f..21910e9 100644 > >> --- a/Documentation/DocBook/media/v4l/compat.xml > >> +++ b/Documentation/DocBook/media/v4l/compat.xml > >> @@ -2545,6 +2545,16 @@ fields changed from _s32 to _u32. > >> > >> > >> > >> + > >> + V4L2 in Linux 3.17 > >> + > >> + > >> + Added V4L2_CID_PAN_SPEED and > >> + V4L2_CID_TILT_SPEED camera controls. > >> + > >> + > >> + > >> + > >> > >>Relation of V4L2 to other Linux multimedia APIs > >> > >> diff --git a/Documentation/DocBook/media/v4l/controls.xml > >> b/Documentation/DocBook/media/v4l/controls.xml > >> index 47198ee..cdf97f0 100644 > >> --- a/Documentation/DocBook/media/v4l/controls.xml > >> +++ b/Documentation/DocBook/media/v4l/controls.xml > >> @@ -3914,6 +3914,27 @@ by exposure, white balance or focus > >> controls. > >> > >> > >> > >> + > >> +>> spanname="id">V4L2_CID_PAN_SPEED > >> + integer > >> + This control turns the > >> +camera horizontally at the specific speed. The unit is undefined. A > >> +positive value moves the camera to the right (clockwise when viewed > >> +from above), a negative value to the left. A value of zero does not > >> +cause or stop the motion. > > > > > > How do we stop/start? > > As mentioned in the last sentence of the paragraph above, setting 0 > stops the movement. > setting non-zero value starts it if needed. > The sentence says "A value of zero does *not* cause or stop the motion.". Perhaps "not" is a typo then? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: dts: Add Peach Pit and Pi dts entry for atmel touchpad
Fabio,
On Wed, Aug 6, 2014 at 6:35 PM, Fabio Estevam wrote:
> On Wed, Aug 6, 2014 at 10:08 PM, Javier Martinez Canillas
> wrote:
>
>> +_8 {
>> + status = "okay";
>> + clock-frequency = <333000>;
>
> Doesn't it work at the more standard 400kHz i2c frequency?
I'm pretty sure that they had signaling problems at 400kHz, but
perhaps Benson will rememer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] pwm: rockchip: Added to support for RK3288 SoC
Caesar,
On Wed, Aug 6, 2014 at 6:27 PM, caesar wrote:
> Doug,
>
> 在 2014年08月07日 06:46, Doug Anderson 写道:
>
>> Caesar,
>>
>> On Thu, Jul 24, 2014 at 3:21 AM, Caesar Wang
>> wrote:
>>>
>>> +static const struct rockchip_pwm_data pwm_data_v1 = {
>>> + .regs.duty = PWM_HRC,
>>> + .regs.period = PWM_LRC,
>>> + .regs.cntr = PWM_CNTR,
>>> + .regs.ctrl = PWM_CTRL,
>>> + .prescaler = PRESCALER,
>>> + .set_enable = rockchip_pwm_set_enable_v1,
>>> +};
>>> +
>>> +static const struct rockchip_pwm_data pwm_data_v2 = {
>>> + .regs.duty = PWM_LRC,
>>> + .regs.period = PWM_HRC,
>>> + .regs.cntr = PWM_CNTR,
>>> + .regs.ctrl = PWM_CTRL,
>>> + .prescaler = PRESCALER-1,
>>> + .set_enable = rockchip_pwm_set_enable_v2,
>>> +};
>>> +
>>> +static const struct rockchip_pwm_data pwm_data_vop = {
>>> + .regs.duty = PWM_LRC,
>>> + .regs.period = PWM_HRC,
>>> + .regs.cntr = PWM_CTRL,
>>> + .regs.ctrl = PWM_CNTR,
>>
>> Did you really mean to flip CTRL and CNTR here? If so, that's super
>> confusing and deserves a comment. AKA, I think the above should not
>> be:
>>
>> + .regs.cntr = PWM_CTRL,
>> + .regs.ctrl = PWM_CNTR,
>>
>> ...but should be
>>
>> + .regs.cntr = PWM_CNTR,
>> + .regs.ctrl = PWM_CTRL,
>>
>> If you didn't mean to flip CTRL and CNTR here, then just get rid of
>> pwm_data_vop and refer to pwm_data_v2. In fact, I'd suggest that you
>> totally remove the "rockchip,vop-pwm" since there's nothing different
>> between "rockchip,rk3288-pwm" and "rockchip,vop-pwm".
>
>
> Sorry,I think it's no problem. the "rockchip,rk3288-pwm" and
> "rockchip,vop-pwm" are seperate PWM controllers.
> They are just different registers address between CNTR and CTRL .
OK, I looked up in the TRM. Right, the CNTR and CTRL are flipped on
the vop. So I think that the only change you need is to add:
#define PWM_VOP_CTRL 0x00
#define PWM_VOP_CNTR 0x0c
...then use these new #defines for the vop structure.
As you have the code written right now it's very confusing. The new
#defines will fix this.
>> Have you validated Thierry's suggestion to allow you to access your
>> memory range?
>
> Yes,we have solve it in lcdc driver.
> The Mark Yao have the submission in [0].
>
> [0]: https://lkml.org/lkml/2014/8/4/20
Excellent! Then we should be able to land after you fix the above.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/8] mm/page_alloc: fix pcp high, batch management
Hi Joonsoo,
On 08/06/2014 03:18 PM, Joonsoo Kim wrote:
> per cpu pages structure, aka pcp, has high and batch values to control
> how many pages we perform caching. This values could be updated
> asynchronously and updater should ensure that this doesn't make any
> problem. For this purpose, pageset_update() is implemented and do some
> memory synchronization. But, it turns out to be wrong when I implemented
> new feature using this. There is no corresponding smp_rmb() in read-side
Out of curiosity, what new feature are you implementing?
IIRC, pageset_update() is used to update high and batch which can be changed
during:
system boot
sysfs
memory hot-plug
So it seems to me that the latter two would have the problems you described
here.
Thanks.
> so that it can't guarantee anything. Without correct updating, system
> could hang in free_pcppages_bulk() due to larger batch value than high.
> To properly update this values, we need to synchronization primitives on
> read-side, but, it hurts allocator's fastpath.
>
> There is another choice for synchronization, that is, sending IPI. This
> is somewhat expensive, but, this is really rare case so I guess it has
> no problem here. However, reducing IPI is very helpful here. Current
> logic handles each CPU's pcp update one by one. To reduce sending IPI,
> we need to re-ogranize the code to handle all CPU's pcp update at one go.
> This patch implement these requirements.
>
> Signed-off-by: Joonsoo Kim
> ---
> mm/page_alloc.c | 139
> ---
> 1 file changed, 80 insertions(+), 59 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index e6fee4b..3e1e344 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3800,7 +3800,7 @@ static void build_zonelist_cache(pg_data_t *pgdat)
> * not check if the processor is online before following the pageset pointer.
> * Other parts of the kernel may not check if the zone is available.
> */
> -static void setup_pageset(struct per_cpu_pageset *p, unsigned long batch);
> +static void setup_pageset(struct per_cpu_pageset __percpu *pcp);
> static DEFINE_PER_CPU(struct per_cpu_pageset, boot_pageset);
> static void setup_zone_pageset(struct zone *zone);
>
> @@ -3846,9 +3846,9 @@ static int __build_all_zonelists(void *data)
>* needs the percpu allocator in order to allocate its pagesets
>* (a chicken-egg dilemma).
>*/
> - for_each_possible_cpu(cpu) {
> - setup_pageset(_cpu(boot_pageset, cpu), 0);
> + setup_pageset(_pageset);
>
> + for_each_possible_cpu(cpu) {
> #ifdef CONFIG_HAVE_MEMORYLESS_NODES
> /*
>* We now know the "local memory node" for each node--
> @@ -4230,24 +4230,59 @@ static int zone_batchsize(struct zone *zone)
> * outside of boot time (or some other assurance that no concurrent updaters
> * exist).
> */
> -static void pageset_update(struct per_cpu_pages *pcp, unsigned long high,
> - unsigned long batch)
> +static void pageset_update(struct zone *zone, int high, int batch)
> {
> - /* start with a fail safe value for batch */
> - pcp->batch = 1;
> - smp_wmb();
> + int cpu;
> + struct per_cpu_pages *pcp;
> +
> + /* start with a fail safe value for batch */
> + for_each_possible_cpu(cpu) {
> + pcp = _cpu_ptr(zone->pageset, cpu)->pcp;
> + pcp->batch = 1;
> + }
> + kick_all_cpus_sync();
> +
> + /* Update high, then batch, in order */
> + for_each_possible_cpu(cpu) {
> + pcp = _cpu_ptr(zone->pageset, cpu)->pcp;
> + pcp->high = high;
> + }
> + kick_all_cpus_sync();
>
> - /* Update high, then batch, in order */
> - pcp->high = high;
> - smp_wmb();
> + for_each_possible_cpu(cpu) {
> + pcp = _cpu_ptr(zone->pageset, cpu)->pcp;
> + pcp->batch = batch;
> + }
> +}
> +
> +/*
> + * pageset_get_values_by_high() gets the high water mark for
> + * hot per_cpu_pagelist to the value high for the pageset p.
> + */
> +static void pageset_get_values_by_high(int input_high,
> + int *output_high, int *output_batch)
> +{
> + *output_batch = max(1, input_high / 4);
> + if ((input_high / 4) > (PAGE_SHIFT * 8))
> + *output_batch = PAGE_SHIFT * 8;
> +}
>
> - pcp->batch = batch;
> +/* a companion to pageset_get_values_by_high() */
> +static void pageset_get_values_by_batch(int input_batch,
> + int *output_high, int *output_batch)
> +{
> + *output_high = 6 * input_batch;
> + *output_batch = max(1, 1 * input_batch);
> }
>
> -/* a companion to pageset_set_high() */
> -static void pageset_set_batch(struct per_cpu_pageset *p, unsigned long batch)
> +static void pageset_get_values(struct zone *zone, int *high, int *batch)
> {
> - pageset_update(>pcp, 6 * batch, max(1UL, 1 * batch));
> + if (percpu_pagelist_fraction) {
> +
Re: [PATCH] alarmtimer: Add the verification code for rtc device error.
On 07/31/2014 02:58 AM, John Stultz wrote: > > Hey! Sorry for the late response here. > > So this seems reasonable as always failing suspend is problematic, but > I worry that for the case where we do have a failure to read or set > the RTC, we'd suspend and not wake up as specified, which is an issue > as well. Absorbing the error silently in these cases would make it > difficult to debug. Should we at least print some output out to help > folks hunt down this sort of issue? > I agree. Most RTC device drivers don't print out the error of read_time. So, I think the higher level like /drivers/rtc/interface.c should check the error and give the information of the RTC device status. I'll try to find a proper point. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.13.y.z extended stable] Patch "locking/mutex: Disable optimistic spinning on some architectures" has been added to staging queue
On Wed, Aug 6, 2014 at 9:55 PM, Kamal Mostafa wrote: > > On Wed, 2014-08-06 at 14:30 -0700, Davidlohr Bueso wrote: >> Well 3.13.y.z isn't an Ubuntu kernel, its upstream, and those archs >> *are* supported. > > Davidlohr's answer is correct: This is not an "Ubuntu kernel". > > 3.13.y.z is an "extended stable" kernel which follows the same rules as > the kernel.org official stable kernels. It contains no Ubuntu-specific > patches, and supports the same arch's as mainline. > > More details about this and the other Canonical-funded-and-hosted > "extended stable" kernel versions is available here: > >> For more information about the 3.13.y.z tree, see >> https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable OK, thank you for clarification. I was unsure as this is not hosted on kernel.org, I thought it was a Ubuntu specific kernel. So we have the following stable kernels as of now: 3.10, 3.12, 3.13, 3.14, 3.15(for a few days), 3.16! Interesting. -- Andev -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] driver/rtc/class.c: check the error after rtc_read_time()
On 07/24/2014 09:19 AM, Andrew Morton wrote: > > So what should rtc do in this case? At present it pretends the read > succeeded. Either way, this doesn't seem to be the place to be making > such policy decisions.. > > > I agree. But, in this case, RTC device driver can not do anything. And if rtc_suspend() returns a minus value, then suspend will be aborted. So, in the worst case, suspend will be failed continually. I think this is not good. Most RTC device drivers don't verify the read time value. Even some drivers just return '0' value(omap, tegra, ...). So, I think the higher level framework like /drivers/rtc/interface.c should check and handle the rtc read time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.13.y.z extended stable] Patch "locking/mutex: Disable optimistic spinning on some architectures" has been added to staging queue
> On Wed, 2014-08-06 at 17:25 -0400, Andev wrote: > > On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa wrote: > > > This is a note to let you know that I have just added a patch titled > > > > > > locking/mutex: Disable optimistic spinning on some architectures > > > > > > to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree > > > which can be found at: > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue > > > > > > This patch is scheduled to be released in version 3.13.11.6. > > > > > > > This patch is specifically for parisc, sparc32, tile32, metag-lock1, > > arc-!llsc and hexagon none of which Ubuntu supports. > > > > Why are you backporting this patch? On Wed, 2014-08-06 at 14:30 -0700, Davidlohr Bueso wrote: > Well 3.13.y.z isn't an Ubuntu kernel, its upstream, and those archs > *are* supported. Davidlohr's answer is correct: This is not an "Ubuntu kernel". 3.13.y.z is an "extended stable" kernel which follows the same rules as the kernel.org official stable kernels. It contains no Ubuntu-specific patches, and supports the same arch's as mainline. More details about this and the other Canonical-funded-and-hosted "extended stable" kernel versions is available here: > For more information about the 3.13.y.z tree, see > https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable -Kamal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sh: bug: add unreachable() to silence warnings
SuperH BUG() have warnings like
kernel/sched/core.c:2692:1: warning: control reaches end of non-void function
[-Wreturn-type]
net/core/ethtool.c:236:1: warning: control reaches end of non-void function
[-Wreturn-type]
Other BUG() implementations
have added unreachable() at end becuase of which I guess
it does not showthese errors. We can silence them using unreachable().
Signed-off-by: Nick Krause
---
arch/sh/include/asm/bug.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sh/include/asm/bug.h b/arch/sh/include/asm/bug.h
index dcf2780..1ae948f 100644
--- a/arch/sh/include/asm/bug.h
+++ b/arch/sh/include/asm/bug.h
@@ -48,6 +48,7 @@ do { \
"i" (__FILE__), \
"i" (__LINE__), "i" (0), \
"i" (sizeof(struct bug_entry))); \
+ unreachable(); \
} while (0)
#define __WARN_TAINT(taint)\
--
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 1/3] libsas: modify SATA error handler
Hi, Dan
I haven't receive your review comments, could you send it to me again, thanks!
PS: I can't login my gmail, so please send mail to this count.
-Original Message-
From: Dan Williams [mailto:dan.j.willi...@intel.com]
Sent: 2014年8月7日 1:22
To: Xiangliang Yu
Cc: jbottom...@parallels.com; t...@kernel.org; todd.e.bra...@intel.com;
lukasz.do...@intel.com; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org
Subject: Re: [PATCH 1/3] libsas: modify SATA error handler
On Wed, Aug 6, 2014 at 3:50 AM, Xiangliang Yu wrote:
> Hi, Dan & James
> How about the patches about support for PM?
> Two months had passed since I submitted the patches.
> Thanks!
>
Did you address my review comments?
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: vmstat: On demand vmstat workers V8
On 08/06/2014 10:12 AM, Christoph Lameter wrote: > On Tue, 5 Aug 2014, Sasha Levin wrote: > >> > I can easily trigger it by cranking up the cpu hotplug code. Just try to >> > frequently offline and online cpus, it should reproduce quickly. > Thats what I thought. > > The test was done with this fix applied right? Nope, I never saw the patch before. Applied it and the problem goes away. Thanks! Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: dts: Add Peach Pit and Pi dts entry for atmel touchpad
Hello Fabio,
On 08/07/2014 03:35 AM, Fabio Estevam wrote:
> On Wed, Aug 6, 2014 at 10:08 PM, Javier Martinez Canillas
> wrote:
>
>> +_8 {
>> + status = "okay";
>> + clock-frequency = <333000>;
>
> Doesn't it work at the more standard 400kHz i2c frequency?
>
Most bits of this DTS snippet have been taken from the downstream Chrome OS 3.8
kernel so I'll let one of the Chromium folks to answer this question.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/8] mm/page_alloc: correct to clear guard attribute in DEBUG_PAGEALLOC
On 08/06/2014 03:18 PM, Joonsoo Kim wrote:
> In __free_one_page(), we check the buddy page if it is guard page.
> And, if so, we should clear guard attribute on the buddy page. But,
> currently, we clear original page's order rather than buddy one's.
> This doesn't have any problem, because resetting buddy's order
> is useless and the original page's order is re-assigned soon.
> But, it is better to correct code.
>
> Additionally, I change (set/clear)_page_guard_flag() to
> (set/clear)_page_guard() and makes these functions do all works
> needed for guard page. This may make code more understandable.
>
> One more thing, I did in this patch, is that fixing freepage accounting.
> If we clear guard page and link it onto isolate buddy list, we should
> not increase freepage count.
>
> Acked-by: Vlastimil Babka
> Signed-off-by: Joonsoo Kim
Reviewed-by: Zhang Yanfei
> ---
> mm/page_alloc.c | 29 -
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b99643d4..e6fee4b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -441,18 +441,28 @@ static int __init debug_guardpage_minorder_setup(char
> *buf)
> }
> __setup("debug_guardpage_minorder=", debug_guardpage_minorder_setup);
>
> -static inline void set_page_guard_flag(struct page *page)
> +static inline void set_page_guard(struct zone *zone, struct page *page,
> + unsigned int order, int migratetype)
> {
> __set_bit(PAGE_DEBUG_FLAG_GUARD, >debug_flags);
> + set_page_private(page, order);
> + /* Guard pages are not available for any usage */
> + __mod_zone_freepage_state(zone, -(1 << order), migratetype);
> }
>
> -static inline void clear_page_guard_flag(struct page *page)
> +static inline void clear_page_guard(struct zone *zone, struct page *page,
> + unsigned int order, int migratetype)
> {
> __clear_bit(PAGE_DEBUG_FLAG_GUARD, >debug_flags);
> + set_page_private(page, 0);
> + if (!is_migrate_isolate(migratetype))
> + __mod_zone_freepage_state(zone, (1 << order), migratetype);
> }
> #else
> -static inline void set_page_guard_flag(struct page *page) { }
> -static inline void clear_page_guard_flag(struct page *page) { }
> +static inline void set_page_guard(struct zone *zone, struct page *page,
> + unsigned int order, int migratetype) {}
> +static inline void clear_page_guard(struct zone *zone, struct page *page,
> + unsigned int order, int migratetype) {}
> #endif
>
> static inline void set_page_order(struct page *page, unsigned int order)
> @@ -594,10 +604,7 @@ static inline void __free_one_page(struct page *page,
>* merge with it and move up one order.
>*/
> if (page_is_guard(buddy)) {
> - clear_page_guard_flag(buddy);
> - set_page_private(page, 0);
> - __mod_zone_freepage_state(zone, 1 << order,
> - migratetype);
> + clear_page_guard(zone, buddy, order, migratetype);
> } else {
> list_del(>lru);
> zone->free_area[order].nr_free--;
> @@ -876,11 +883,7 @@ static inline void expand(struct zone *zone, struct page
> *page,
>* pages will stay not present in virtual address space
>*/
> INIT_LIST_HEAD([size].lru);
> - set_page_guard_flag([size]);
> - set_page_private([size], high);
> - /* Guard pages are not available for any usage */
> - __mod_zone_freepage_state(zone, -(1 << high),
> - migratetype);
> + set_page_guard(zone, [size], high, migratetype);
> continue;
> }
> #endif
>
--
Thanks.
Zhang Yanfei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
Hello Tomasz, Thanks a lot for your feedback. On 08/07/2014 03:14 AM, Tomasz Figa wrote: > Hi Javier, > > > Have you observed an actual failure due to this? I believe that Yes, I found this issue since the driver was not taking into account the value defined in the edge/level type cells from the "interrupts" DT property. Only doing the change in the following patch was not enough: [PATCH 1/1] ARM: dts: Add Peach Pit and Pi dts entry for atmel touchpad [0]. > irq_of_parse_and_map() already sets up IRQ trigger type based on DT > data, by calling irq_create_of_mapping() which in turn calls > irq_set_irq_type(). > Right but somehow when the IRQ is actually requested the type is overwritten by the value passed to request_threaded_irq() and interrupts are not being generated by the device without this patch. Do you think that this is a bug in the "interrupt-parent" irqchip driver or the IRQ core? I'm not that familiar with the IRQ subsystem. >> >> +if (client->dev.of_node) >> +irqflags = irq_get_trigger_type(client->irq); > > It might be a bit cleaner to just assign the flags to pdata->irqflags in > mxt_parse_dt() instead. That would also account for the fact that pdata, > if provided, should have priority over DT. > You are totally right, also this will break if CONFIG_OF is not enabled since dev.of_node will not be defined. While this already is taken into account for mxt_parse_dt() by defining an empty function. I'll change it in v2 if getting the flags from the driver is the right approach instead of fixing the irqchip driver or the IRQ core. > Best regards, > Tomasz > Best regards, Javier [0]: http://www.spinics.net/lists/kernel/msg1802099.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: dts: Add Peach Pit and Pi dts entry for atmel touchpad
On Wed, Aug 6, 2014 at 10:08 PM, Javier Martinez Canillas
wrote:
> +_8 {
> + status = "okay";
> + clock-frequency = <333000>;
Doesn't it work at the more standard 400kHz i2c frequency?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] KVM: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table
Paolo Bonzini wrote on 2014-08-06: > Il 06/08/2014 16:03, Zhang, Yang Z ha scritto: >> Paolo Bonzini wrote on 2014-07-31: >>> Probably, the guest is masking the interrupt in the redirection >>> table in the interrupt routine, i.e. while the interrupt is set in a >>> LAPIC's ISR. >>> The simplest fix is to ignore the masking state, we would rather >>> have an unnecessary exit rather than a missed IRQ ACK and anyway >>> IOAPIC interrupts are not as performance-sensitive as for example MSIs. >> >> I feel this fixing may hurt performance in some cases. If the mask >> bit is set, this means the vector in this entry may be used by other >> devices(like a assigned device). But here you set it in eoi exit >> bitmap and this will cause vmexit on each EOI which should not happen. > > Note that this *was* reported on an assigned device. > > IOAPIC should not be a performance-sensitive path. High-performance > assigned devices should be using MSIs. Let me give an example to see whether my concern is a real problem: Guest allocates a vector and set it in IOAPIC entry to deliver interrupt. Later it masks the IOAPIC entry(means stop the corresponding device) and assign this vector to a MSI device. With this patch, even the vector is not used by IOAPIC, but it still set eoi exit bitmap unconditionally. The subsequent EOIs to MSI device will force vmexit. Could this happen? I think the right fixing is to check the ISR plus TMR to construct the eoi exit bitmap. > > Paolo Best regards, Yang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] UEFI arm64: add noefi boot param
On 08/06/14 at 02:40pm, Ard Biesheuvel wrote: > On 6 August 2014 10:38, Dave Young wrote: > > > > Adding a noefi boot param like in X86 to disable efi runtime services > > support. > > > > This will be useful for debugging uefi problems. Also it will be useful > > for later kexec/kdump work. Kexec on uefi support in X86 depends on a fixed > > vm > > area specific for uefi runtime 1:1 mapping, kernel will switch to a > > different > > page table for any uefi runtime callback in virtual mode. In arm64 similar > > work probably is necessary. But kexec boot will just works with 'noefi' with > > the limitaion of lacking runtime services. The runtime services is not > > critical > > for kdump kernel for now. So as for kexec/kdump just leave the 1:1 mapping a > > future work. > > > > Can we find a better name? You will still be using the UEFI memory map > rather than the DT memory nodes (which will have been deleted by the > stub), and things like SMBIOS and ACPI that hinge off UEFI remain > enabled as well. > Hi, Ard Leif suggested efi=noruntime, I think that will be better to you? Thanks for review. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] pwm: rockchip: Added to support for RK3288 SoC
Doug,
在 2014年08月07日 06:46, Doug Anderson 写道:
Caesar,
On Thu, Jul 24, 2014 at 3:21 AM, Caesar Wang wrote:
+static const struct rockchip_pwm_data pwm_data_v1 = {
+ .regs.duty = PWM_HRC,
+ .regs.period = PWM_LRC,
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
+ .prescaler = PRESCALER,
+ .set_enable = rockchip_pwm_set_enable_v1,
+};
+
+static const struct rockchip_pwm_data pwm_data_v2 = {
+ .regs.duty = PWM_LRC,
+ .regs.period = PWM_HRC,
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
+ .prescaler = PRESCALER-1,
+ .set_enable = rockchip_pwm_set_enable_v2,
+};
+
+static const struct rockchip_pwm_data pwm_data_vop = {
+ .regs.duty = PWM_LRC,
+ .regs.period = PWM_HRC,
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
Did you really mean to flip CTRL and CNTR here? If so, that's super
confusing and deserves a comment. AKA, I think the above should not
be:
+ .regs.cntr = PWM_CTRL,
+ .regs.ctrl = PWM_CNTR,
...but should be
+ .regs.cntr = PWM_CNTR,
+ .regs.ctrl = PWM_CTRL,
If you didn't mean to flip CTRL and CNTR here, then just get rid of
pwm_data_vop and refer to pwm_data_v2. In fact, I'd suggest that you
totally remove the "rockchip,vop-pwm" since there's nothing different
between "rockchip,rk3288-pwm" and "rockchip,vop-pwm".
Sorry,I think it's no problem. the "rockchip,rk3288-pwm" and
"rockchip,vop-pwm" are seperate PWM controllers.
They are just different registers address between CNTR and CTRL .
Have you validated Thierry's suggestion to allow you to access your
memory range?
Yes,we have solve it in lcdc driver.
The Mark Yao have the submission in [0].
[0]: https://lkml.org/lkml/2014/8/4/20
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] sched: deferred set priority (dprio)
On Tue, Aug 5, 2014 at 10:41 PM, Mike Galbraith
wrote:
>> > SCHED_NORMAL where priority escalation does not work as preemption proofing
>>
>> Remember, DPRIO is not for lock holders only.
>>
>> Using DPRIO within SCHED_NORMAL policy would make sense for an application
>> that
>> has "soft" time-urgent section where it believes strong protection
>> from preemption
>> is not really necessary, and just a greater claim to CPU time share would do,
>> in cases where the application does not know beforehand if the section will
>> be
>> short or long, and in majority of cases is short (sub-millisecond), but
>> occasionally can take longer.
>
> Every single time that SCHED_NORMAL task boosts its priority (nice)
> during a preemption, the math has already been done, vruntime has
> already been adjusted.
> Sure, when it gets the CPU back, its usage will
> be weighed differently, it will become more resistant to preemption, but
> in no way immune. There is nothing remotely deterministic about this,
> making it somewhat of an oxymoron when combined with critical section.
But you overlooked the point I was trying to convey in the paragraph you
are responding to.
Apart from SCHED_NORMAL being a marginal use case, if it is used at all, I do
not see it being used for lock-holding or similar critical section where an
application wants to avoid the preemption.
I can see DPRIO(SCHED_NORMAL) being used in the same cases as an application
would use nice for a temporary section, i.e. when it has a job that needs to be
processed relatively promptly over some time interval but not really
super-urgently and hard guarantees are not needed, i.e. when the application
simply wants to have an improved claim for CPU resources compared to normal
threads over let us say the next half-second or so. It is ok if the application
gets preempted, all it cares about is a longer timeframe ("next half-second")
rather than shorter and immediate timeframe ("next millisecond").
The only reason why anyone would want to use DPRIO instead of regular nice in
this case is because it might be unknown beforehand whether the job will be
short or might take a longer time, with majority of work items being very short
but occasionally taking longer. In this case using DPRIO would let to cut the
overhead for majority of section instances. To reiterate, this is a marginal
and most likely rare use case, but given the existence of uniform interface
I just do not see why to block it on purpose.
> If some kthread prioritizes _itself_ and mucks up application
> performance, file a bug report, that kthread is busted. Anything a user
> or application does with realtime priorities is on them.
kthreads do not need RT, they just use spinlocks ;-)
On a serious note though, I am certainly not saying that injudicious use of RT
(or even nice) cannot disrupt the system, but is it reason enough to summarily
condemn the judicious use as well?
>> I disagree. The exact problem is that it is not a developer who initiates the
>> preemption, but the kernel or another part of application code that is
>> unaware
>> of other thread's condition and doing it blindly, lacking the information
>> about
>> the state of the thread being preempted and the expected cost of its
>> preemption
>> in this state. DPRIO is a way to communicate this information.
> What DPRIO clearly does NOT do is to describe critical sections to the
> kernel.
First of all let's reflect that your argument is not with DPRIO as such. DPRIO
after all is not a separate scheduling mode, but just a method to reduce the
overhead of regular set_priority calls (i.e. sched_setattr & friends).
You argument is with the use of elevated priority as such, and you are saying
that using RT priority range (or high nice) does not convey to the kernel the
information about the critical section.
I do not agree with this, not wholly anyway. First of all, it is obvious that
set_priority does convey some information about the section, so perhaps a more
accurate re-formulation of your argument could be that it is imperfect,
insufficient information.
Let's try to imagine then what could make more perfect information. It
obviously should be some cost function describing the cost that would be
incurred if the task gets preempted. Something that would say (if we take the
simplest form) "if you preempt me within the next T microseconds (unless I
cancel or modify this mode), this preemption would incur cost X upfront further
accruing at a rate Y".
One issue I see with this approach is that in real life it might be very hard
for a developer to quantify the values for X, Y and T. Developer can easily
know that he wants to avoid the preemption in a given section, but actually
quantifying the cost of preemption (X, Y) would take a lot of effort
(benchmarking) and furthermore really cannot be assigned statically, as the
cost varies depending on the load pattern and site-specific configuration.
Furthermore, when dealing with multiple
Re: [PATCH 1/2] UEFI arm64: add noefi boot param
On 08/06/14 at 03:01pm, Matt Fleming wrote: > On Wed, 06 Aug, at 02:29:41PM, Leif Lindholm wrote: > > On Wed, Aug 06, 2014 at 02:20:21PM +0100, Matt Fleming wrote: > > > > Since this is really turning an x86-specific feature into a generic > > > > one, could it be moved to core code? > > > > Maybe an efi.mask, reusing the efi_enabled defines, with an > > > > efi_disabled macro? > > > > > > Why the new efi_disabled() and efi.mask? This is all achievable with > > > efi_enabled() and efi.flags, in fact, this kind of thing is exactly why > > > they were invented. > > > > Because this flag is indicating which facilities we should not try to > > enable, rather than which facilities we have enabled. > > > > The EFI_RUNTIME_SERVICES flag is set after successful call to > > set_virtual_address_map. The apparent intent of "noefi" is to prevent > > that call from being made in the first place. > > > > Anyway, it was just a suggestion - main point was it would make sense > > to share the code. > > Definitely. > > Dave, below is the kind of thing that I had in mind. Please Cc the Xen > and SGI folks when you submit your next version because they're likely > to be hit the hardest by any changes to EFI_RUNTIME_SERVICES and > "noefi". > > Obviously the addition of "efi=noruntime" is needed on top, but that's > about 6 lines of code. [snip] Matt, will file a new version based on your code. I will also address the failure case in enter virtual mode. Currently in x86, there's cases such as efi_map_regions failure and efi call set_virtual_address_map, in case those failures it should be better to unset the EFI_RUNTIME_SERVICES in efi.flags instead of do noting or panic. As for Xen and SGI people? I have not been following all the efi threads so I'm not sure who exactly I should cc, could you tell me? Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
Hi Javier,
On 07.08.2014 02:48, Javier Martinez Canillas wrote:
> The Atmel maXTouch driver assumed that the IRQ type flags will
> always be passed using platform data but this is not true when
> booting using Device Trees. In these setups the interrupt type
> was ignored by the driver when requesting an IRQ.
>
> This means that it will fail if a machine specified other type
> than IRQ_TYPE_NONE. The right approach is to get the IRQ flags
> that was parsed by OF from the "interrupt" Device Tree propery.
Have you observed an actual failure due to this? I believe that
irq_of_parse_and_map() already sets up IRQ trigger type based on DT
data, by calling irq_create_of_mapping() which in turn calls
irq_set_irq_type().
>
> Signed-off-by: Javier Martinez Canillas
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 03b8571..0fb56c9 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2130,6 +2131,7 @@ static int mxt_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> struct mxt_data *data;
> const struct mxt_platform_data *pdata;
> int error;
> + unsigned long irqflags;
>
> pdata = dev_get_platdata(>dev);
> if (!pdata) {
> @@ -2156,8 +2158,13 @@ static int mxt_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> init_completion(>reset_completion);
> init_completion(>crc_completion);
>
> + if (client->dev.of_node)
> + irqflags = irq_get_trigger_type(client->irq);
It might be a bit cleaner to just assign the flags to pdata->irqflags in
mxt_parse_dt() instead. That would also account for the fact that pdata,
if provided, should have priority over DT.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] bug: Add unreachable() to generic BUG() to silence warnings
Architectures which use generic BUG() have warnings like
kernel/sched/core.c:2692:1: warning: control reaches end of non-void function
[-Wreturn-type]
net/core/ethtool.c:236:1: warning: control reaches end of non-void function
[-Wreturn-type]
Other BUG() implementations
have added unreachable() at end but generic does not. I guess
that is why
it showing these errors. We can silence them using unreachable().
Signed-off-by: Nick Krause
---
include/asm-generic/bug.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 630dd23..effcc82 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -48,6 +48,7 @@ struct bug_entry {
#define BUG() do { \
printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
panic("BUG!"); \
+ unreachable(); \
} while (0)
#endif
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ARM: dts: Add Peach Pit and Pi dts entry for atmel touchpad
From: Sjoerd Simons
The Peach Pit and Pi boards have an Atmel maXTouch device.
Add the needed Device Tree nodes to support it.
Signed-off-by: Sjoerd Simons
[javier.martinez: added linux,gpio-keymap property and changed IRQ type]
Signed-off-by: Javier Martinez Canillas
---
With only this patch the touchpad is probed but interrupts are not being
generated. The following is needed to have a fully functional touchpad:
[PATCH 1/2] "Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting"
https://lkml.org/lkml/2014/8/6/585
arch/arm/boot/dts/exynos5420-peach-pit.dts | 29 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 29 +
2 files changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 228a6b1..7dce444 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include
#include
+#include
#include "exynos5420.dtsi"
/ {
@@ -157,6 +158,27 @@
};
};
+_8 {
+ status = "okay";
+ clock-frequency = <333000>;
+
+ trackpad@4b {
+ compatible="atmel,maxtouch";
+ reg=<0x4b>;
+ interrupt-parent=<>;
+ interrupts=<1 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-source;
+ pinctrl-names = "default";
+ pinctrl-0 = <_irq>;
+ linux,gpio-keymap = < BTN_LEFT
+ BTN_TOOL_FINGER
+ BTN_TOOL_DOUBLETAP
+ BTN_TOOL_TRIPLETAP
+ BTN_TOOL_QUADTAP
+ BTN_TOOL_QUINTTAP >;
+ };
+};
+
_9 {
status = "okay";
clock-frequency = <40>;
@@ -249,6 +271,13 @@
samsung,pin-drv = <0>;
};
+ trackpad_irq: trackpad-irq {
+ samsung,pins = "gpx1-1";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
power_key_irq: power-key-irq {
samsung,pins = "gpx1-2";
samsung,pin-function = <0>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3ee48b..de946b3 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include
#include
+#include
#include "exynos5800.dtsi"
/ {
@@ -155,6 +156,27 @@
};
};
+_8 {
+ status = "okay";
+ clock-frequency = <333000>;
+
+ trackpad@4b {
+ compatible="atmel,maxtouch";
+ reg=<0x4b>;
+ interrupt-parent=<>;
+ interrupts=<1 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-source;
+ pinctrl-names = "default";
+ pinctrl-0 = <_irq>;
+ linux,gpio-keymap = < BTN_LEFT
+ BTN_TOOL_FINGER
+ BTN_TOOL_DOUBLETAP
+ BTN_TOOL_TRIPLETAP
+ BTN_TOOL_QUADTAP
+ BTN_TOOL_QUINTTAP >;
+ };
+};
+
_9 {
status = "okay";
clock-frequency = <40>;
@@ -247,6 +269,13 @@
samsung,pin-drv = <0>;
};
+ trackpad_irq: trackpad-irq {
+ samsung,pins = "gpx1-1";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
power_key_irq: power-key-irq {
samsung,pins = "gpx1-2";
samsung,pin-function = <0>;
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] seq_file: Allow private data to be supplied on seq_open
Al Viro writes: > On Wed, Aug 06, 2014 at 05:16:49PM +0100, Rob Jones wrote: > >> I'm not quite sure I understand your meaning when you say "via seq_open" >> though, that function call format needs to stay the same or lots of >> code will break, so I can't just add the third parameter on the end. >> (C++ does have *some* advantages!) Can you clarify, please? > > seq_open_private() can be implemented as call of seq_open() + > assignment... This is why I object to the name seq_open_priv() for the new code. seq_open_private() is already implemented and base on seq_open(). And the names are close enough together it is confusing :( Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/8] fix freepage count problems in memory isolation
Hi Joonsoo, The first 3 patches in this patchset are in a bit of mess. On 08/06/2014 03:18 PM, Joonsoo Kim wrote: > Hello, > > This patchset aims at fixing problems during memory isolation found by > testing my patchset [1]. > > These are really subtle problems so I can be wrong. If you find what I am > missing, please let me know. > > Before describing bugs itself, I first explain definition of freepage. > > 1. pages on buddy list are counted as freepage. > 2. pages on isolate migratetype buddy list are *not* counted as freepage. > 3. pages on cma buddy list are counted as CMA freepage, too. > 4. pages for guard are *not* counted as freepage. > > Now, I describe problems and related patch. > > Patch 1: If guard page are cleared and merged into isolate buddy list, > we should not add freepage count. > > Patch 4: There is race conditions that results in misplacement of free > pages on buddy list. Then, it results in incorrect freepage count and > un-availability of freepage. > > Patch 5: To count freepage correctly, we should prevent freepage from > being added to buddy list in some period of isolation. Without it, we > cannot be sure if the freepage is counted or not and miscount number > of freepage. > > Patch 7: In spite of above fixes, there is one more condition for > incorrect freepage count. pageblock isolation could be done in pageblock > unit so we can't prevent freepage from merging with page on next > pageblock. To fix it, start_isolate_page_range() and > undo_isolate_page_range() is modified to process whole range at one go. > With this change, if input parameter of start_isolate_page_range() and > undo_isolate_page_range() is properly aligned, there is no condition for > incorrect merging. > > Without patchset [1], above problem doesn't happens on my CMA allocation > test, because CMA reserved pages aren't used at all. So there is no > chance for above race. > > With patchset [1], I did simple CMA allocation test and get below result. > > - Virtual machine, 4 cpus, 1024 MB memory, 256 MB CMA reservation > - run kernel build (make -j16) on background > - 30 times CMA allocation(8MB * 30 = 240MB) attempts in 5 sec interval > - Result: more than 5000 freepage count are missed > > With patchset [1] and this patchset, I found that no freepage count are > missed so that I conclude that problems are solved. > > These problems can be possible on memory hot remove users, although > I didn't check it further. > > This patchset is based on linux-next-20140728. > Please see individual patches for more information. > > Thanks. > > [1]: Aggressively allocate the pages on cma reserved memory > https://lkml.org/lkml/2014/5/30/291 > > Joonsoo Kim (8): > mm/page_alloc: correct to clear guard attribute in DEBUG_PAGEALLOC > mm/isolation: remove unstable check for isolated page > mm/page_alloc: fix pcp high, batch management > mm/isolation: close the two race problems related to pageblock > isolation > mm/isolation: change pageblock isolation logic to fix freepage > counting bugs > mm/isolation: factor out pre/post logic on > set/unset_migratetype_isolate() > mm/isolation: fix freepage counting bug on > start/undo_isolat_page_range() > mm/isolation: remove useless race handling related to pageblock > isolation > > include/linux/page-isolation.h |2 + > mm/internal.h |5 + > mm/page_alloc.c| 223 +- > mm/page_isolation.c| 292 > +++- > 4 files changed, 368 insertions(+), 154 deletions(-) > -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Input: atmel_mxt_ts - Add keycodes array example
The Atmel maXTouch driver allows to dynamically define the event keycodes set that the device is capable of. This may not be evident when reading the DT binding document so add an example to make it easier to understand how this works. Also, the current documentation says that the array limit is four entries but the driver dynamically allocates the keymap array and does not limit the array size. Signed-off-by: Javier Martinez Canillas --- Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt index baef432..be50476 100644 --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt @@ -11,7 +11,7 @@ Required properties: Optional properties for main touchpad device: -- linux,gpio-keymap: An array of up to 4 entries indicating the Linux +- linux,gpio-keymap: An array of entries indicating the Linux keycode generated by each GPIO. Linux keycodes are defined in . @@ -22,4 +22,10 @@ Example: reg = <0x4b>; interrupt-parent = <>; interrupts = ; + linux,gpio-keymap = < BTN_LEFT + BTN_TOOL_FINGER + BTN_TOOL_DOUBLETAP + BTN_TOOL_TRIPLETAP + BTN_TOOL_QUADTAP + BTN_TOOL_QUINTTAP >; }; -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
The Atmel maXTouch driver assumed that the IRQ type flags will
always be passed using platform data but this is not true when
booting using Device Trees. In these setups the interrupt type
was ignored by the driver when requesting an IRQ.
This means that it will fail if a machine specified other type
than IRQ_TYPE_NONE. The right approach is to get the IRQ flags
that was parsed by OF from the "interrupt" Device Tree propery.
Signed-off-by: Javier Martinez Canillas
---
drivers/input/touchscreen/atmel_mxt_ts.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 03b8571..0fb56c9 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2130,6 +2131,7 @@ static int mxt_probe(struct i2c_client *client, const
struct i2c_device_id *id)
struct mxt_data *data;
const struct mxt_platform_data *pdata;
int error;
+ unsigned long irqflags;
pdata = dev_get_platdata(>dev);
if (!pdata) {
@@ -2156,8 +2158,13 @@ static int mxt_probe(struct i2c_client *client, const
struct i2c_device_id *id)
init_completion(>reset_completion);
init_completion(>crc_completion);
+ if (client->dev.of_node)
+ irqflags = irq_get_trigger_type(client->irq);
+ else
+ irqflags = pdata->irqflags;
+
error = request_threaded_irq(client->irq, NULL, mxt_interrupt,
-pdata->irqflags | IRQF_ONESHOT,
+irqflags | IRQF_ONESHOT,
client->name, data);
if (error) {
dev_err(>dev, "Failed to register interrupt\n");
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Input: hyperv-keyboard: register as a wakeup source
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov > > Hi Dmitry, > > Sorry, I didn't realize it's not public... :-) > > > > I'll remove the line and re-send the patch. > > > > No need to resend, I already applied it. > Dmitry, That's great! :-) Thanks a lot! -- Dexuan
Re: [GIT PULL] Global signal cleanup
Hi Richard, On Wed, 06 Aug 2014 13:29:10 +0200 Richard Weinberger wrote: > > Am 06.08.2014 13:27, schrieb Stephen Rothwell: > > > > On Wed, 06 Aug 2014 13:18:54 +0200 Richard Weinberger > > wrote: > >> > >> the following changes since commit > >> 19583ca584d6f574384e17fe7613dfaeadcdc4a6: > >> > >> Linux 3.16 (2014-08-03 15:25:02 -0700) > >> > >> are available in the git repository at: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal-cleanup > > > > This has all been rebased onto v3.16 but none of the patches changed. > > This was my indention. Also I've added some acks. > Did I screw something up? We discourage people from rebasing their trees just before asking Linus to pull them unless they have a good reason. Adding Acks is not necessarily a good reason. It may be a different thing if you rewrite your tree (without changing it base) and, given that none of your actual patches changed, that would have worked for you. In your case, since you haven't updated the branch (signal_v4) that I fetch for linux-next, its doubly bad as, after Linus' pulls your tree, I will have two copies of all those patches in my tree - which could easily lead to conflicts that I really don't need to have. Also, note that the fact that the actual patches did not change at all means that either you missed some change that coudl have justified the rebase, or the rebase was unnecessary (since the things you are patching did not change). -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH] staging: nokia_h4: nokia_core.c: use usleep_range() instead of msleep()
On Wed, Aug 06, 2014 at 11:30:55PM +0200, Pavel Machek wrote: > On Wed 2014-08-06 13:56:33, Marcel Holtmann wrote: > > Hi Greg, > > > > >>> Creating this patch for the Eudyptula Challenge. > > >>> Replaced msleep() for a delay < 20ms with a > > >>> usleep_range() between 1us and 15000us. Also > > >>> inserted a blank line after adeclaration. > > >> > > >> So you are changing timings without testing. Plus, > > >> burning CPU power instead of sleeping. > > >> > > >> Seems you'll need another patch for the challenge :-). > > > > > > I actually wonder if anybody is seriously working on this > > > driver. My concern with the staging drivers has always > > > been that we are quick with merging them when the work on > > > getting them into upstream shape is actually hard. > > > However reality is once they are in staging nobody is > > > doing the work to clean them up and fix the issues. > > > > There is active work on merging n900 changes. > > >>> > > >>> Really? Where? > > >>> > > >> > > >> You can look at elinux wiki where is table how process is going: > > >> http://elinux.org/N900 > > >> > > >> Also look at planed future list and its progress: > > >> http://elinux.org/N900/Changelog > > >> > > >> You can see that drivers are including step by step. > > > > > > I'm not going to dig through random web pages, sorry. If patches aren't > > > sent to me for a driver, I consider it dead, that's only fair for me > > > given my workload, don't you think? > > > > > And no, it does not progress as quickly as I'd like, but > > we'll get there. It is also requirement for n900 FM radio > > receiving... > > > > > Greg, instead of wasting our time with this, can we just > > > remove this driver from staging. > > > > Please don't. > > >>> > > >>> As there has not been any real work on it since it has been > > >>> merged, I don't see why I shouldn't remove it. If you do get > > >>> some work done on it, you can always revert the removal and > > >>> continue on. But the existance of code in staging that is > > >>> not progressing forward at all is something that I don't like > > >>> at all, and will be doing a large sweep of soon to remove. > > >>> > > >>> thanks, > > >>> > > >>> greg k-h > > >> > > >> Just look how much time took to include my patch for radio- > > >> bcm2048 (fm radio part of this chip) which fixing wrong overflow > > >> check. I sent it at the end of December and... yes it is still > > >> not included in linus tree. Now it is somethere in media tree and > > >> probably will be pulled in next merge window. > > >> > > >> This means that it takes about half of year to include patches > > >> for these drivers. > > > > > > Just because the media drivers take a long time to get fixes merged, > > > don't use that as an excuse to not fix up the staging drivers. > > > > > > In fact, it sounds like you have lots of time while that patch is > > > getting merged, why not work on fixing up the staging driver? :) > > > > and 2 month later, we still have nothing accomplished with this driver. > > > > So this driver is 6 month in staging and not a single commit to address > > anything in the TODO file. I only see pointless coding style change. > > > > There is a reason why I dislike staging drivers. And this is exactly it. It > > gets treated as dumping ground. So can we please remove this driver now. > > Maybe someone finally wakes up and does their promised job. > > > > Yeah, so I clearly make a mistake of cleaning the driver up _before_ > merging it into staging. No, the mistake was that you didn't ever follow it up with any real work, not that it was "cleaned up" at all. > And yes, I'm currently trying to get 3.16 working in the qemu, which > is prerequisite for any useful n900 work. So I guess I'll queue up a patch to delete this for 3.17-rc2. Pavel, if you get the device working properly, we can easily revert the deletion and you can send follow-on patches to fix things up properly. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: hyperv-keyboard: register as a wakeup source
On Wed, Aug 6, 2014 at 5:19 PM, Dexuan Cui wrote: > > > -Original Message- > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > > Sent: Thursday, August 7, 2014 4:34 AM > > To: Dexuan Cui > > On Fri, Aug 01, 2014 at 07:28:24AM -0700, Dexuan Cui wrote: > > > With this patch, we can press a key to wake up the VM after the VM > > executes > > > "echo freeze > /sys/power/state". > > > > > > This addresses part of > > https://bugzilla.redhat.com/show_bug.cgi?id=1086100 > > > > I am sorry but this bug is not open to the public. Please avoid > > mentioning such bugs in changelogs. Otherwise I'll apply it. > Hi Dmitry, > Sorry, I didn't realize it's not public... :-) > > I'll remove the line and re-send the patch. > No need to resend, I already applied it. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] staging: iio: accel: Add blank lines between declarations and code
This patch adds missing blank lines between declarations and code and
fixes lines starting by spaces, satisfying checkpatch.pl.
Signed-off-by: Murilo Opsfelder Araujo
---
drivers/staging/iio/accel/adis16201_core.c | 5 +++--
drivers/staging/iio/accel/adis16203_core.c | 2 ++
drivers/staging/iio/accel/adis16204_core.c | 1 +
drivers/staging/iio/accel/adis16209_core.c | 1 +
drivers/staging/iio/accel/adis16240_core.c | 1 +
drivers/staging/iio/accel/lis3l02dq_core.c | 4
drivers/staging/iio/accel/lis3l02dq_ring.c | 1 +
drivers/staging/iio/accel/sca3000_core.c | 1 +
8 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16201_core.c
b/drivers/staging/iio/accel/adis16201_core.c
index 50ba1fa..7eae5fd 100644
--- a/drivers/staging/iio/accel/adis16201_core.c
+++ b/drivers/staging/iio/accel/adis16201_core.c
@@ -111,6 +111,7 @@ static int adis16201_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan->type) {
@@ -131,8 +132,8 @@ static int adis16201_write_raw(struct iio_dev *indio_dev,
}
static const struct iio_chan_spec adis16201_channels[] = {
- ADIS_SUPPLY_CHAN(ADIS16201_SUPPLY_OUT, ADIS16201_SCAN_SUPPLY, 0, 12),
- ADIS_TEMP_CHAN(ADIS16201_TEMP_OUT, ADIS16201_SCAN_TEMP, 0, 12),
+ ADIS_SUPPLY_CHAN(ADIS16201_SUPPLY_OUT, ADIS16201_SCAN_SUPPLY, 0, 12),
+ ADIS_TEMP_CHAN(ADIS16201_TEMP_OUT, ADIS16201_SCAN_TEMP, 0, 12),
ADIS_ACCEL_CHAN(X, ADIS16201_XACCL_OUT, ADIS16201_SCAN_ACC_X,
BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14),
ADIS_ACCEL_CHAN(Y, ADIS16201_YACCL_OUT, ADIS16201_SCAN_ACC_Y,
diff --git a/drivers/staging/iio/accel/adis16203_core.c
b/drivers/staging/iio/accel/adis16203_core.c
index f472137..fbbe93f 100644
--- a/drivers/staging/iio/accel/adis16203_core.c
+++ b/drivers/staging/iio/accel/adis16203_core.c
@@ -37,6 +37,7 @@ static int adis16203_write_raw(struct iio_dev *indio_dev,
struct adis *st = iio_priv(indio_dev);
/* currently only one writable parameter which keeps this simple */
u8 addr = adis16203_addresses[chan->scan_index];
+
return adis_write_reg_16(st, addr, val & 0x3FFF);
}
@@ -50,6 +51,7 @@ static int adis16203_read_raw(struct iio_dev *indio_dev,
int bits;
u8 addr;
s16 val16;
+
switch (mask) {
case IIO_CHAN_INFO_RAW:
return adis_single_conversion(indio_dev, chan,
diff --git a/drivers/staging/iio/accel/adis16204_core.c
b/drivers/staging/iio/accel/adis16204_core.c
index 19eaebc..4c8acbc 100644
--- a/drivers/staging/iio/accel/adis16204_core.c
+++ b/drivers/staging/iio/accel/adis16204_core.c
@@ -119,6 +119,7 @@ static int adis16204_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan->type) {
diff --git a/drivers/staging/iio/accel/adis16209_core.c
b/drivers/staging/iio/accel/adis16209_core.c
index 374dc6e..b2c7aed 100644
--- a/drivers/staging/iio/accel/adis16209_core.c
+++ b/drivers/staging/iio/accel/adis16209_core.c
@@ -44,6 +44,7 @@ static int adis16209_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan->type) {
diff --git a/drivers/staging/iio/accel/adis16240_core.c
b/drivers/staging/iio/accel/adis16240_core.c
index 74ace2a..205d6d0 100644
--- a/drivers/staging/iio/accel/adis16240_core.c
+++ b/drivers/staging/iio/accel/adis16240_core.c
@@ -163,6 +163,7 @@ static int adis16240_write_raw(struct iio_dev *indio_dev,
int bits = 10;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
val16 = val & ((1 << bits) - 1);
diff --git a/drivers/staging/iio/accel/lis3l02dq_core.c
b/drivers/staging/iio/accel/lis3l02dq_core.c
index 898653c..f5e145c 100644
--- a/drivers/staging/iio/accel/lis3l02dq_core.c
+++ b/drivers/staging/iio/accel/lis3l02dq_core.c
@@ -212,6 +212,7 @@ static int lis3l02dq_write_thresh(struct iio_dev *indio_dev,
int val, int val2)
{
u16 value = val;
+
return lis3l02dq_spi_write_reg_s16(indio_dev,
LIS3L02DQ_REG_THS_L_ADDR,
value);
@@ -226,6 +227,7 @@ static int lis3l02dq_write_raw(struct iio_dev *indio_dev,
int ret = -EINVAL, reg;
u8 uval;
s8 sval;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
if (val > 255 || val < -256)
@@ -302,6 +304,7 @@ static ssize_t lis3l02dq_read_frequency(struct device *dev,
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
int ret, len = 0;
s8 t;
+
ret = lis3l02dq_spi_read_reg_8(indio_dev,
[PATCH v3 2/2] staging: iio: accel: sca3000_core.c: Adjust code to fit 80-chars limit
Signed-off-by: Murilo Opsfelder Araujo --- drivers/staging/iio/accel/sca3000_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/iio/accel/sca3000_core.c b/drivers/staging/iio/accel/sca3000_core.c index bc53fedb..e4e5639 100644 --- a/drivers/staging/iio/accel/sca3000_core.c +++ b/drivers/staging/iio/accel/sca3000_core.c @@ -506,7 +506,8 @@ static int sca3000_read_raw(struct iio_dev *indio_dev, mutex_unlock(>lock); return ret; } - *val = ((st->rx[0] & 0x3F) << 3) | ((st->rx[1] & 0xE0) >> 5); + *val = ((st->rx[0] & 0x3F) << 3) | + ((st->rx[1] & 0xE0) >> 5); } mutex_unlock(>lock); return IIO_VAL_INT; -- 2.1.0.rc1.204.gae8bc8d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] staging: iio: accel: Multiple coding style fixes
The following patches fix almost all warnings reported by checkpatch.pl. v2 -> v3 changes: - Folded blank line patches into a single patch. - Fit code in 80-chars limit and still be human-readable. Murilo Opsfelder Araujo (2): staging: iio: accel: Add blank lines between declarations and code staging: iio: accel: sca3000_core.c: Adjust code to fit 80-chars limit drivers/staging/iio/accel/adis16201_core.c | 5 +++-- drivers/staging/iio/accel/adis16203_core.c | 2 ++ drivers/staging/iio/accel/adis16204_core.c | 1 + drivers/staging/iio/accel/adis16209_core.c | 1 + drivers/staging/iio/accel/adis16240_core.c | 1 + drivers/staging/iio/accel/lis3l02dq_core.c | 4 drivers/staging/iio/accel/lis3l02dq_ring.c | 1 + drivers/staging/iio/accel/sca3000_core.c | 4 +++- 8 files changed, 16 insertions(+), 3 deletions(-) -- 2.1.0.rc1.204.gae8bc8d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Input: hyperv-keyboard: register as a wakeup source
> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: Thursday, August 7, 2014 4:34 AM > To: Dexuan Cui > On Fri, Aug 01, 2014 at 07:28:24AM -0700, Dexuan Cui wrote: > > With this patch, we can press a key to wake up the VM after the VM > executes > > "echo freeze > /sys/power/state". > > > > This addresses part of > https://bugzilla.redhat.com/show_bug.cgi?id=1086100 > > I am sorry but this bug is not open to the public. Please avoid > mentioning such bugs in changelogs. Otherwise I'll apply it. Hi Dmitry, Sorry, I didn't realize it's not public... :-) I'll remove the line and re-send the patch. Thanks, -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH to be tested] serial: msm_serial: add missing sysrq handling
Stephen,
Can you test this patch on v 1.3 hardware? It works on my v 1.4.
If you use kdmx2, the way to send a break is '~B'. The previous
key pressed must be for the '~' escape to be recognized.
Thanks!
-Frank
From: Frank Rowand
Add missing sysrq handling to msm_serial.
Signed-off-by: Frank Rowand
---
drivers/tty/serial/msm_serial.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
Index: b/drivers/tty/serial/msm_serial.c
===
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -126,6 +126,8 @@ static void handle_rx_dm(struct uart_por
while (count > 0) {
unsigned int c;
+ unsigned char *cp;
+ int res;
sr = msm_read(port, UART_SR);
if ((sr & UART_SR_RX_READY) == 0) {
@@ -135,15 +137,29 @@ static void handle_rx_dm(struct uart_por
c = msm_read(port, UARTDM_RF);
if (sr & UART_SR_RX_BREAK) {
port->icount.brk++;
- if (uart_handle_break(port))
+ if (uart_handle_break(port)) {
+ count -= 1;
continue;
+ }
} else if (sr & UART_SR_PAR_FRAME_ERR)
port->icount.frame++;
- /* TODO: handle sysrq */
- tty_insert_flip_string(tport, (char *),
- (count > 4) ? 4 : count);
- count -= 4;
+ spin_unlock(>lock);
+ res = uart_handle_sysrq_char(port, c);
+ spin_lock(>lock);
+
+ cp = (unsigned char *)
+ if (res) {
+ count -= 1;
+ tty_insert_flip_string(tport, cp + 1,
+ (count > 3) ? 3 : count);
+ count -= (count > 3) ? 3 : count;
+ } else {
+ tty_insert_flip_string(tport, cp,
+ (count > 4) ? 4 : count);
+ count -= (count > 4) ? 4 : count;
+ }
+
}
spin_unlock(>lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86: Add "make tinyconfig" to configure the tiniest possible kernel
On Wed, Aug 06, 2014 at 04:37:54PM -0700, David Rientjes wrote: > On Wed, 6 Aug 2014, Josh Triplett wrote: > > On Wed, Aug 06, 2014 at 03:38:56PM -0700, David Rientjes wrote: > > > On Wed, 6 Aug 2014, Josh Triplett wrote: > > > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > > > > index 1568678..2b5ca16 100644 > > > > --- a/arch/x86/Makefile > > > > +++ b/arch/x86/Makefile > > > > @@ -257,6 +257,10 @@ PHONY += kvmconfig > > > > kvmconfig: > > > > $(call mergeconfig,kvm_guest) > > > > > > > > +PHONY += tinyconfig > > > > +tinyconfig: allnoconfig > > > > > > Calling allnoconfig here makes "make tinyconfig" default to CONFIG_X86_32 > > > even on 64 bit platforms and the caller would need to explicitly do > > > "make ARCH=x86_64 tinyconfig" to avoid it. It's not clear that this is > > > intended from the documentation of tinyconfig, that tiniest == 32 bit by > > > default. > > > > Calling allnoconfig was quite intentional; this is intended to be the > > smallest possible configuration, and unlike kvmconfig (which modifies an > > existing configuration to make it suitable for a KVM guest), this > > intentionally creates a specific new configuration from scratch. > > > > 32-bit produces a far smaller kernel than 64-bit, so having that as the > > default for tinyconfig seems quite appropriate. As you showed, it's > > easy enough to override it if needed. I'd expect many potential users > > of tinyconfig for embedded systems to start with tinyconfig and then > > immediately use menuconfig to enable a pile of additional options. > > In that case, any reason to make tinyconfig x86 only? The set of configuration options may vary by architecture. For instance, NOHIGHMEM only exists on x86. So, at a minimum, different architectures will require different versions of tiny.config. The target itself and the common options could theoretically be shared, but that would require splitting the configuration, and it isn't obvious where the non-arch-specific tiny.config would live. There doesn't appear to be any precedent for that kind of setup; only x86 has a configuration other than defconfigs (specifically, kvm_guest.config). I don't think it's likely that new targets like this will pop up often in the future, either. Nonetheless, I could modify scripts/kconfig/Makefile to add this target instead, if someone has a good suggestion for where the non-arch-specific tiny.config should live. (kernel/configs/ ?) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: WARN_ON_ONCE(in_nmi()) hit in irq_work_queue_on
On Wed, Aug 06, 2014 at 07:01:51PM +0200, Peter Zijlstra wrote:
> > Sigh, that's d84153d6c96f61a so that's been there a while, and been
> > broken equally long.
> >
> > So this is where we run a low period (!freq) hardware event on a
> > nohz_full cpu or so? And because it throttles, we need to kick the tick
> > into action to unthrottle it.
> >
> > I suppose there's a good reason I never build with that nohz_full
> > nonsense enabled :/
> >
> > Not sure how we should go fix that, you can't just issue random IPIs
> > from NMI context.
>
> OK, thinking one more second would've done it, how about so?
>
> ---
> include/linux/perf_event.h | 7 ---
> kernel/events/core.c | 8 +++-
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 707617a8c0f6..177411e3ffc4 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -421,9 +421,10 @@ struct perf_event {
> struct fasync_struct*fasync;
>
> /* delayed work for NMIs and such */
> - int pending_wakeup;
> - int pending_kill;
> - int pending_disable;
> + int pending_kill : 16;
> + int pending_wakeup: 1;
> + int pending_disable : 1;
> + int pending_nohz_kick : 1;
> struct irq_work pending;
>
> atomic_tevent_limit;
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 1cf24b3e42ec..e95fca20e26f 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4258,6 +4258,11 @@ static void perf_pending_event(struct irq_work *entry)
> event->pending_wakeup = 0;
> perf_event_wakeup(event);
> }
> +
> + if (event->pending_nohz_kick) {
> + event->pending_nohz_kick = 0;
> + tick_nohz_full_kick();
> + }
> }
>
> /*
> @@ -5431,7 +5436,8 @@ static int __perf_event_overflow(struct perf_event
> *event,
> __this_cpu_inc(perf_throttled_count);
> hwc->interrupts = MAX_INTERRUPTS;
> perf_log_throttle(event, 0);
> - tick_nohz_full_kick();
> + event->pending_nohz_kick = 1;
> + irq_work_queue(>pending);
> ret = 1;
> }
> }
In fact the problem has arised since the recent irq work patches I did.
There I've changed tick_nohz_full_kick() to use irq_work_queue_on() instead
of irq_work_queue() so it has become NMI unsafe by accident.
So I'd rather suggest this instead of queuing two levels of irq_work:
diff --git a/include/linux/tick.h b/include/linux/tick.h
index 8a4987f..fed88b5 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -181,13 +181,8 @@ static inline bool tick_nohz_full_cpu(int cpu)
extern void tick_nohz_init(void);
extern void __tick_nohz_full_check(void);
+extern void tick_nohz_full_kick(void);
extern void tick_nohz_full_kick_cpu(int cpu);
-
-static inline void tick_nohz_full_kick(void)
-{
- tick_nohz_full_kick_cpu(smp_processor_id());
-}
-
extern void tick_nohz_full_kick_all(void);
extern void __tick_nohz_task_switch(struct task_struct *tsk);
#else
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index d4ccb96..8e0d347 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -225,6 +225,12 @@ static DEFINE_PER_CPU(struct irq_work,
nohz_full_kick_work) = {
.func = nohz_full_kick_work_func,
};
+void tick_nohz_full_kick(void)
+{
+ if (!tick_nohz_full_cpu(smp_processor_id()))
+ irq_work_queue(&__get_cpu_var(nohz_full_kick_work));
+}
+
/*
* Kick the CPU if it's full dynticks in order to force it to
* re-evaluate its dependency on the tick and restart it if 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 2/2] x86: Add "make tinyconfig" to configure the tiniest possible kernel
On Wed, 6 Aug 2014, Josh Triplett wrote: > On Wed, Aug 06, 2014 at 03:38:56PM -0700, David Rientjes wrote: > > On Wed, 6 Aug 2014, Josh Triplett wrote: > > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > > > index 1568678..2b5ca16 100644 > > > --- a/arch/x86/Makefile > > > +++ b/arch/x86/Makefile > > > @@ -257,6 +257,10 @@ PHONY += kvmconfig > > > kvmconfig: > > > $(call mergeconfig,kvm_guest) > > > > > > +PHONY += tinyconfig > > > +tinyconfig: allnoconfig > > > > Calling allnoconfig here makes "make tinyconfig" default to CONFIG_X86_32 > > even on 64 bit platforms and the caller would need to explicitly do > > "make ARCH=x86_64 tinyconfig" to avoid it. It's not clear that this is > > intended from the documentation of tinyconfig, that tiniest == 32 bit by > > default. > > Calling allnoconfig was quite intentional; this is intended to be the > smallest possible configuration, and unlike kvmconfig (which modifies an > existing configuration to make it suitable for a KVM guest), this > intentionally creates a specific new configuration from scratch. > > 32-bit produces a far smaller kernel than 64-bit, so having that as the > default for tinyconfig seems quite appropriate. As you showed, it's > easy enough to override it if needed. I'd expect many potential users > of tinyconfig for embedded systems to start with tinyconfig and then > immediately use menuconfig to enable a pile of additional options. > In that case, any reason to make tinyconfig x86 only? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support 32 CPUs
On Wed, Aug 6, 2014 at 3:16 PM, Russell King - ARM Linux
wrote:
> On Wed, Aug 06, 2014 at 10:28:37AM -0700, Kees Cook wrote:
>> That's what I was thinking. I tried this, and things are still weird,
>> though I think I'm narrowing it down. I made the early_pte_alloc
>> happen, but after boot it doesn't show up in
>> /sys/kernel/debug/kernel_page_tables. When I attempt a fixmap text
>> poke, I get this out of dmesg (lkdtm is reporting the address returned
>> from the patch mapping):
>>
>> lkdtm: 80421ac0 mapped RW via ffdefac0
>> Unable to handle kernel paging request at virtual address ffdefac0
>> pgd = 9e888000
>> [ffdefac0] *pgd=9fffc811, *pte=, *ppte=
>> Internal error: Oops: 807 [#1] SMP ARM
>>
>> The target address (0xffdefac0) is correct; it's in the range set aside:
>>
>> #define FIXADDR_START 0xffc0UL
>> #define FIXADDR_END 0xffe0UL
>> #define FIXADDR_TOP (FIXADDR_END - PAGE_SIZE)
>>
>> enum fixed_addresses {
>> /* Support 16 CPUs for kmap as the first region of fixmap entries. */
>> FIX_KMAP_BEGIN,
>> FIX_KMAP_END = 15,
>>
>> /* Support writing RO kernel text via kprobes, jump labels, etc. */
>> FIX_TEXT_POKE0,
>> FIX_TEXT_POKE1,
>>
>> __end_of_fixed_addresses
>> };
>>
>> But the resulting PTE is in totally the wrong location as reported by
>> /sys/kernel/debug/kernel_page_tables:
>>
>> ---[ Fixmap Area ]---
>> 0xfffef000-0x 4K RW NX SHD MEM/CACHED/WBWA
>>
>> I continue to dig...
>
> This sounds like you have an erroneous merge conflict resolution. You
> seem to be poking into TOP_PTE rather than fixmap_page_table.
Yeah, agreed. This did turn out to be the issue, so I reworked the
set_fixmap routine to aim at the correct pte. The result seems to
work, so I after retesting everything, I sent the series out. So
close! :)
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] Export the temperatures via hwmon
On Wed, Aug 06, 2014 at 09:05:03PM +, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> Export the temperature via the hwmon subsystem.
> See the list below for the sensors exported:
>
> $ cd /sys/devices/temperature/hwmon/hwmon0
> $ echo "name: $(cat name)"; for i in temp*; do echo "$i: $(cat $i)"; done
> name: therm_windtunnel
> temp1_input: 59312
> temp1_label: CPU
> temp2_input: 36750
> temp2_label: Case
> temp3_input: 37750
> temp3_label: Case2
>
Makes me wonder why you don't report the fan speed through hwmon.
> The Case2 temperature is the sensor temperature inside the adm1030.
>
There are standard hwmon drivers for lm75, ds1775, and adm1030.
Personally I think it would make more sense to use those directly.
But I guess that would be for another day.
> Signed-off-by: Goffredo Baroncelli
> ---
> drivers/macintosh/therm_windtunnel.c | 103
> +--
> 1 file changed, 99 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/macintosh/therm_windtunnel.c
> b/drivers/macintosh/therm_windtunnel.c
> index b6cba98..a6757d7 100644
> --- a/drivers/macintosh/therm_windtunnel.c
> +++ b/drivers/macintosh/therm_windtunnel.c
> @@ -37,6 +37,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -58,9 +60,12 @@ static struct {
> struct i2c_client *thermostat;
> struct i2c_client *fan;
>
> + struct device *hwmon;
> +
> int overheat_temp; /* 100% fan at this
> temp */
> int overheat_hyst;
> int temp;
> + int casetemp2;
> int casetemp;
> int fan_level; /* active fan_table
> setting */
>
> @@ -120,6 +125,75 @@ static DEVICE_ATTR(case_temperature, S_IRUGO,
> show_case_temperature, NULL );
> static DEVICE_ATTR(fan_level, S_IRUGO, show_fan_level, NULL);
>
>
> +static ssize_t
> +show_temp1(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d%03d\n", x.temp>>8, (x.temp & 0xff)*1000>>8);
I personally prefer if code follows coding style, with spaces around operands,
and if calculations are less cryptic.
> +}
> +
> +static ssize_t
> +show_temp1_label(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + return sprintf(buf, "CPU\n");
> +}
> +
> +static ssize_t
> +show_temp2(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d%03d\n", x.casetemp>>8,
> + (x.casetemp & 0xff)*1000>>8);
> +}
> +
> +static ssize_t
> +show_temp2_label(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + return sprintf(buf, "Case\n");
> +}
> +
> +
> +static ssize_t
> +show_temp3(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d%03d\n", x.casetemp2>>8,
> + (x.casetemp2 & 0xff)*1000>>8);
... and aligned second lines.
> +}
> +
> +static ssize_t
> +show_temp3_label(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + return sprintf(buf, "Case2\n");
> +}
> +
> +#define TWT_ATTRIB(name, func) \
> + static SENSOR_DEVICE_ATTR(name##_input, S_IRUGO, func, NULL, 0); \
> + static SENSOR_DEVICE_ATTR(name##_label, S_IRUGO, func##_label, \
> + NULL, 0)
> +
> +TWT_ATTRIB(temp1, show_temp1);
> +TWT_ATTRIB(temp2, show_temp2);
> +TWT_ATTRIB(temp3, show_temp3);
> +
> +
A single empty line should be sufficient. Personally I am also not
a fan of such macros (and neither is checkpatch), and prefer the use
of direct macros as less confusing.
Also, using three different functions for three different attributes
where the only difference is the variable name defeats the purpose
of using SENSOR_DEVICE_ATTR, which has an index variable for exactly
that reason. I would suggest to either use an indexed array to access
the temperatures, or use DEVICE_ATTR.
> +static struct attribute *therm_windtunnel_attributes[] = {
> + _dev_attr_temp1_input.dev_attr.attr,
> + _dev_attr_temp1_label.dev_attr.attr,
> + _dev_attr_temp2_input.dev_attr.attr,
> + _dev_attr_temp2_label.dev_attr.attr,
> + _dev_attr_temp3_input.dev_attr.attr,
> + _dev_attr_temp3_label.dev_attr.attr,
> +
> + NULL,
> +};
> +
> +static const struct attribute_group therm_windtunnel_attr_group = {
> + .attrs = therm_windtunnel_attributes,
> +};
> +
> +static const struct attribute_group *therm_windtunnel_attr_groups[] = {
> + _windtunnel_attr_group,
> + NULL,
> +};
ATTRIBUTE_GROUPS() is a nice and useful macro.
> +
> //
> /* controller thread */
> //
> @@
Re: [PATCH 3/4] brd: Fix all partitions BUGs
On Wed, 2014-08-06 at 14:33 +0300, Boaz Harrosh wrote:
> This patch fixes up brd's partitions scheme, now enjoying all worlds.
>
> The MAIN fix here is that currently if one fdisks some partitions,
> a BAD bug will make all partitions point to the same start-end sector
> ie: 0 - brd_size And an mkfs of any partition would trash the partition
> table and the other partition.
>
> Another fix is that "mount -U uuid" did not work, because of the
> GENHD_FL_SUPPRESS_PARTITION_INFO flag.
>
> So NOW the logic goes like this:
> * max_part - Just says how many minors to reserve between devices
> But in any way, there can be as many partition as requested.
> If minors between devices ends, then dynamic 259-major ids will
> be allocated on the fly.
> The default is now max_part=1, which means all partitions devt
> will be from the dynamic major-range.
> (If persistent partition minors is needed use max_part=)
>
> * Creation of new devices on the fly still/always work:
> mknod /path/devnod b 1 X
> fdisk -l /path/devnod
> Will create a new device if (X / max_part) was not already
> created before. (Just as before)
>
> partitions on the dynamically created device will work as well
> Same logic applies with minors as with the pre-created ones.
>
> TODO: dynamic grow of device size, maybe through sysfs. So each
> device can have it's own size.
With this patch we end up in what feels like a weird place where we're half
using the old scheme of major/minor allocation, and half in the world of
dynamic major/minors. Devices have a major of 1 and minors that increment by
1, but partitions have a major of 259 (BLOCK_EXT_MAJOR):
brw-rw 1 root disk 1, 0 Aug 6 14:10 /dev/ram0
brw-rw 1 root disk 1, 1 Aug 6 14:13 /dev/ram1
brw-rw 1 root disk 259, 0 Aug 6 14:14 /dev/ram1p1
brw-rw 1 root disk 259, 1 Aug 6 14:13 /dev/ram1p2
brw-rw 1 root disk 259, 2 Aug 6 14:14 /dev/ram1p51
For NVMe and PRD you get a major of 259 all around:
brw-rw 1 root disk 259, 0 Aug 6 16:55 /dev/pmem0
brw-rw 1 root disk 259, 2 Aug 6 16:55 /dev/pmem0p1
brw-rw 1 root disk 259, 3 Aug 6 16:55 /dev/pmem0p2
brw-rw 1 root disk 259, 1 Aug 6 16:54 /dev/pmem1
It could be that this is fine, but it just smells fishy to me I guess.
Also, it looks like you can still create a new device with this patch, but you
can't create partitions on that device. Not sure if this is just what you get
when you dynamically create a device on the fly, or if it's a symptom of
something larger.
- Ross
>
> Signed-off-by: Boaz Harrosh
> ---
> drivers/block/brd.c | 93
> +
> 1 file changed, 36 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/block/brd.c b/drivers/block/brd.c
> index 3f07cb4..9673704 100644
> --- a/drivers/block/brd.c
> +++ b/drivers/block/brd.c
> @@ -447,16 +447,18 @@ static const struct block_device_operations brd_fops = {
> /*
> * And now the modules code and kernel interface.
> */
> -static int rd_nr;
> -int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
> -static int max_part;
> -static int part_shift;
> +static int rd_nr = CONFIG_BLK_DEV_RAM_COUNT;
> module_param(rd_nr, int, S_IRUGO);
> MODULE_PARM_DESC(rd_nr, "Maximum number of brd devices");
> +
> +int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
> module_param(rd_size, int, S_IRUGO);
> MODULE_PARM_DESC(rd_size, "Size of each RAM disk in kbytes.");
> +
> +static int max_part = 1;
> module_param(max_part, int, S_IRUGO);
> -MODULE_PARM_DESC(max_part, "Maximum number of partitions per RAM disk");
> +MODULE_PARM_DESC(max_part, "Num Minors to reserve between devices");
> +
> MODULE_LICENSE("GPL");
> MODULE_ALIAS_BLOCKDEV_MAJOR(RAMDISK_MAJOR);
> MODULE_ALIAS("rd");
> @@ -502,15 +504,15 @@ static struct brd_device *brd_alloc(int i)
> brd->brd_queue->limits.discard_zeroes_data = 1;
> queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, brd->brd_queue);
>
> - disk = brd->brd_disk = alloc_disk(1 << part_shift);
> + disk = brd->brd_disk = alloc_disk(max_part);
> if (!disk)
> goto out_free_queue;
> disk->major = RAMDISK_MAJOR;
> - disk->first_minor = i << part_shift;
> + disk->first_minor = i * max_part;
> disk->fops = _fops;
> disk->private_data = brd;
> disk->queue = brd->brd_queue;
> - disk->flags |= GENHD_FL_SUPPRESS_PARTITION_INFO;
> + disk->flags = GENHD_FL_EXT_DEVT;
> sprintf(disk->disk_name, "ram%d", i);
> set_capacity(disk, rd_size * 2);
>
> @@ -532,10 +534,11 @@ static void brd_free(struct brd_device *brd)
> kfree(brd);
> }
>
> -static struct brd_device *brd_init_one(int i)
> +static struct brd_device *brd_init_one(int i, bool *new)
> {
> struct brd_device *brd;
>
> + *new = false;
> list_for_each_entry(brd, _devices, brd_list) {
>
Re: [PATCH net-next v3] tcp: md5: check md5 signature without socket lock
From: Dmitry Popov
Date: Thu, 7 Aug 2014 02:38:22 +0400
> Since a8afca032 (tcp: md5: protects md5sig_info with RCU) tcp_md5_do_lookup
> doesn't require socket lock, rcu_read_lock is enough. Therefore socket lock is
> no longer required for tcp_v{4,6}_inbound_md5_hash too, so we can move these
> calls (wrapped with rcu_read_{,un}lock) before bh_lock_sock:
> from tcp_v{4,6}_do_rcv to tcp_v{4,6}_rcv.
>
> Signed-off-by: Dmitry Popov
Applied, 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 v4 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting
> From: diand...@google.com [mailto:diand...@google.com] On Behalf Of Doug
> Anderson
> Sent: Wednesday, August 06, 2014 3:25 PM
>
> On Tue, Aug 5, 2014 at 6:01 PM, Kever Yang wrote:
> > According to the "dr_mode", the otg controller can work as
> > device role and host role. Some boards always want to use host mode
> > and some other boards want to use gadget mode. We use the dts setting
> > to set dwc2's mode, rather than fixing it to whatever hardware says.
> >
> > Signed-off-by: Kever Yang
> > Acked-by: Paul Zimmerman
> > ---
> >
> > Changes in v4:
> > - From Doug's suggestion:
> > -- remove dr_mode init from Kconfig code
> > -- change the commit meesage
> >
> > Changes in v3:
> > - fix the odd spacing in dwc2_hsotg struct
> > - From Jingoo's suggestion:
> > change the commit message
> > - add dr_mode init from Kconfig
> >
> > Changes in v2:
> > - put spaces around '+' operator
> > - expand the comment for dr_mode
> > - handle dr_mode is USB_DR_MODE_OTG
> >
> > drivers/usb/dwc2/core.c | 18 ++
> > drivers/usb/dwc2/core.h | 5 +
> > drivers/usb/dwc2/platform.c | 4
> > 3 files changed, 27 insertions(+)
>
> I think this patch still makes sense even though we don't have a
> combined driver yet. Perhaps Paul or Dihn can confirm.
Yes, it should be fine.
> We could potentially do something based on KConfig (like you did in
> patch set #3), but it wouldn't really make sense to do that until
> after Dihn's work lands.
>
>
> > diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> > index 27d2c9b..738bec2 100644
> > --- a/drivers/usb/dwc2/core.c
> > +++ b/drivers/usb/dwc2/core.c
> > @@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
> > {
> > u32 greset;
> > int count = 0;
> > + u32 gusbcfg;
> >
> > dev_vdbg(hsotg->dev, "%s()\n", __func__);
> >
> > @@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
> > }
> > } while (greset & GRSTCTL_CSFTRST);
> >
> > + if (hsotg->dr_mode == USB_DR_MODE_HOST) {
> > + gusbcfg = readl(hsotg->regs + GUSBCFG);
> > + gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
> > + gusbcfg |= GUSBCFG_FORCEHOSTMODE;
> > + writel(gusbcfg, hsotg->regs + GUSBCFG);
> > + } else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
> > + gusbcfg = readl(hsotg->regs + GUSBCFG);
> > + gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
> > + gusbcfg |= GUSBCFG_FORCEDEVMODE;
> > + writel(gusbcfg, hsotg->regs + GUSBCFG);
> > + } else if (hsotg->dr_mode == USB_DR_MODE_OTG) {
> > + gusbcfg = readl(hsotg->regs + GUSBCFG);
> > + gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
> > + gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
> > + writel(gusbcfg, hsotg->regs + GUSBCFG);
>
> I think the third case here won't be too useful until the combined
> driver, but it shouldn't hurt, right?
Right. For the existing drivers, it shouldn't change anything, since
nothing currently sets dr_mode. And with Kever's other patches, it
forces host mode on the Rockchip platform, which is all that is required
for now, if I understand correctly.
--
Paul
Re: [RFC PATCH] kprobes: arm: enable OPTPROBES for arm 32
On Wed, Aug 06, 2014 at 03:23:23PM +0100, Jon Medhurst (Tixy) wrote:
> On Tue, 2014-08-05 at 15:28 +0800, Wang Nan wrote:
> > +static inline int
> > +arm_branch_to_addr(unsigned int *pinst, void *src, void *dest)
> > +{
> > + unsigned int inst = 0xea00;
> > + long offset = (unsigned long)(dest) -
> > + ((unsigned long)(src) + 8);
> > + if ((offset > 0x3fc) || (offset < -0x3fc)) {
> > + printk(KERN_WARNING "Failed to instrument %pS to %pS\n", src,
> > dest);
> > + return -EINVAL;
> > + }
> > +
> > + inst |= (((unsigned long)offset) >> 2) & (0x00ffUL);
> > + *pinst = inst;
> > + return 0;
> > +}
> > +
>
> This looks remarkably similar to the code in arch/arm/kernel/insn.c so I
> think you can probably just use the existing arm_gen_branch() function.
Which would be a better idea as the version found in insn.c is not
buggy.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] kprobes: arm: enable OPTPROBES for arm 32
On Tue, Aug 05, 2014 at 03:28:17PM +0800, Wang Nan wrote:
> This patch introduce kprobeopt for ARM 32.
>
> Limitations:
> - Currently only kernel compiled with ARM ISA is supported.
>
> - offset between probe point and kprobe pre_handler must not larger
> than 64MiB. Masami Hiramatsu suggests replacing 2 words, it will
> make things complex. Futher patch can make such optimization.
Why 64MiB? I think you mean +/- 32MiB.
> +static inline int
> +arm_branch_to_addr(unsigned int *pinst, void *src, void *dest)
> +{
> + unsigned int inst = 0xea00;
> + long offset = (unsigned long)(dest) -
> + ((unsigned long)(src) + 8);
> + if ((offset > 0x3fc) || (offset < -0x3fc)) {
> + printk(KERN_WARNING "Failed to instrument %pS to %pS\n", src,
> dest);
> + return -EINVAL;
> + }
> +
> + inst |= (((unsigned long)offset) >> 2) & (0x00ffUL);
So if offset is 0x3fc, then inst becomes 0xea00 |
((0x3fc >> 2) & 0x00ff), or 0xeaff.
If offset is -4, then offset is 0xfffc. So inst becomes 0xea0 |
((0xfffc >> 2) & 0x00ff), or 0xeaff.
To prove it, let's disassemble this instruction:
<.text>:
0: eafcb 0xfff8
Yep, it branches backwards.
The second point is you don't mean -0x3fc - that's not how two's
complement arithmetic works - the branch instruction offset is a
signed integer of 24 bits. Bit 23 is the sign bit, it's maximum
positive value is 0x7f and it's maximum negative value is 0x80.
Hence, you actually mean here 0x1fc (which gives the maximum
forward branch) and -0x200 (which gives the maximum backward
branch).
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: nand: omap: Revert to using software ECC by default
On Wed, Aug 6, 2014 at 11:02 AM, Roger Quadros wrote: > Hi Gražvydas, > > On 08/05/2014 07:15 PM, Grazvydas Ignotas wrote: >> On Tue, Aug 5, 2014 at 1:11 PM, Roger Quadros wrote: >>> For v3.12 and prior, 1-bit Hamming code ECC via software was the >>> default choice. Commit c66d039197e4 in v3.13 changed the behaviour >>> to use 1-bit Hamming code via Hardware using a different ECC layout >>> i.e. (ROM code layout) than what is used by software ECC. >>> >>> This ECC layout change causes NAND filesystems created in v3.12 >>> and prior to be unusable in v3.13 and later. So revert back to >>> using software ECC by default if an ECC scheme is not explicitely >>> specified. >>> >>> This defect can be observed on the following boards during legacy boot >>> >>> -omap3beagle >>> -omap3touchbook >>> -overo >>> -am3517crane >>> -devkit8000 >>> -ldp >>> -3430sdp >> >> omap3pandora is also using sw ecc, with ubifs. Some time ago I tried >> booting mainline (I think it was 3.14) with rootfs on NAND, and while >> it did boot and reached a shell, there were lots of ubifs errors, fs >> got corrupted and I lost all my data. I used to be able to boot >> mainline this way fine sometime ~3.8 release. It's interesting that >> 3.14 was able to read the data, even with wrong ecc setup. > > This is due to another bug introduced in 3.7 by commit > 65b97cf6b8deca3ad7a3e00e8316bb89617190fb. > Because of that bug (i.e. inverted CS_MASK in omap_calculate_ecc), > omap_calculate_ecc() always fails with -EINVAL and calculated ECC bytes are > always 0. I'll be sending a patch to fix that as well. But that will only > affect the cases where OMAP_ECC_HAM1_CODE_HW is used which happened for > pandora from 3.13 onwards. > >> >> Do you think it's safe again to boot ubifs created on 3.2 after >> applying this series? >> > > Yes. If you boot pandora using legacy boot (non DT method), it passes 0 for > .ecc_opt in pandora_nand_data. This used to mean > OMAP_ECC_HAMMING_CODE_DEFAULT which is software ecc. i.e. NAND_ECC_SOFT with > default ECC layout. Until the above mentioned commits changed the meaning. We > now call that option OMAP_ECC_HAM1_CODE_SW. > > Please let me know if it works for you. Thanks. Yes it does, thank you. Tested-by: Grazvydas Ignotas Found something new in dmesg though: [1.542755] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc [1.549621] nand: Micron MT29F4G16ABBDA3W [1.553894] nand: 512MiB, SLC, page size: 2048, OOB size: 64 [1.560058] nand: WARNING: omap2-nand.0: the ECC used on your system is too weak compared to the one required by the NAND chip Do you think it's best to migrate to different ECC scheme? It would be better to avoid that so that users can freely change kernels and the bootloader wouldn't have to be changed.. -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
