Re: [PATCH 3.10 00/11] 3.10.88-stable review
On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.88 release. > There are 11 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 13 22:45:08 UTC 2015. > Anything received after that time might be too late. Compiled and booted on x86_32. No errors in dmesg. cross_compiled with allmodconfig: i386 - pass x86_64 - pass alphacheck - pass arm - pass cris - failed m68k - pass mips - pass powerpc - pass s390 - failed sparc - pass sparc64 - pass tile - failed tilegx - failed xtensa - failed build report at https://travis-ci.org/sudipm-mukherjee/parport/builds/79959776 regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]
On Fri, 2015-09-11 at 21:43 -0700, Ming Lin wrote:
> On Fri, Sep 11, 2015 at 2:43 PM, Mike Snitzer wrote:
> > Ming, Jens, others:
> >
> > Please see this BZ comment that speaks to a 4.3 regression due to the
> > late bio splitting changes:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1247382#c41
> >
> > But inlined here so we can continue on list:
> > (In reply to Josh Boyer from comment #40)
> >> The function that was fixed in 4.2 doesn't exist any longer in
> >> 4.3.0-0.rc0.git6.1.fc24. That kernel corresponds to Linux
> >> v4.2-6105-gdd5cdb48edfd which contains commit
> >> 8ae126660fddbeebb9251a174e6fa45b6ad8f932, which removed it completely. So
> >> whatever fix was made in dm_merge_bvec doesn't seem to have made it to
> >> whatever replaced it.
> >
> > The dm core fix to dm_merge_bvec was commit bd4aaf8f9b ("dm: fix
> > dm_merge_bvec regression on 32 bit systems"). But I'm not sure there is
> > a clear equivalent in the late bio splitting code that replaced block
> > core's merge_bvec logic.
> >
> > merge_bvec was all about limiting bios (by asking "can/should this page
> > be added to this bio?") whereas the late bio splitting is more "build
> > the bios as large as possible and worry about splitting later".
> >
> > Regardless, this regression needs to be reported to Ming Lin
> > , Jens Axboe and the others involved in
> > maintaining the late bio splitting changes in block core.
>
> I'm looking at it now.
I tried rawhide-20150903 boot.iso and rawhide-20150904 boot.iso.
0903 boot.iso is OK, but 0904 boot.iso just stuck at "Reached target
Basic System". So I can't see the panic.
http://www.minggr.net/pub/20150912/rawhide-20150904-boot.iso.png
I'll run test on 32bit VM, see if I can reproduce the bug.
Adam,
Could you also help to confirm that commit 7140aaf is OK and commit
8ae1266 is bad?
Thanks,
Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]
On Sat, Sep 12, 2015 at 12:34 AM, Ming Lin wrote:
> On Fri, 2015-09-11 at 21:43 -0700, Ming Lin wrote:
>> On Fri, Sep 11, 2015 at 2:43 PM, Mike Snitzer wrote:
>> > Ming, Jens, others:
>> >
>> > Please see this BZ comment that speaks to a 4.3 regression due to the
>> > late bio splitting changes:
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1247382#c41
>> >
>> > But inlined here so we can continue on list:
>> > (In reply to Josh Boyer from comment #40)
>> >> The function that was fixed in 4.2 doesn't exist any longer in
>> >> 4.3.0-0.rc0.git6.1.fc24. That kernel corresponds to Linux
>> >> v4.2-6105-gdd5cdb48edfd which contains commit
>> >> 8ae126660fddbeebb9251a174e6fa45b6ad8f932, which removed it completely. So
>> >> whatever fix was made in dm_merge_bvec doesn't seem to have made it to
>> >> whatever replaced it.
>> >
>> > The dm core fix to dm_merge_bvec was commit bd4aaf8f9b ("dm: fix
>> > dm_merge_bvec regression on 32 bit systems"). But I'm not sure there is
>> > a clear equivalent in the late bio splitting code that replaced block
>> > core's merge_bvec logic.
>> >
>> > merge_bvec was all about limiting bios (by asking "can/should this page
>> > be added to this bio?") whereas the late bio splitting is more "build
>> > the bios as large as possible and worry about splitting later".
>> >
>> > Regardless, this regression needs to be reported to Ming Lin
>> > , Jens Axboe and the others involved in
>> > maintaining the late bio splitting changes in block core.
>>
>> I'm looking at it now.
>
> I tried rawhide-20150903 boot.iso and rawhide-20150904 boot.iso.
> 0903 boot.iso is OK, but 0904 boot.iso just stuck at "Reached target
> Basic System". So I can't see the panic.
> http://www.minggr.net/pub/20150912/rawhide-20150904-boot.iso.png
>
> I'll run test on 32bit VM, see if I can reproduce the bug.
>
> Adam,
>
> Could you also help to confirm that commit 7140aaf is OK and commit
> 8ae1266 is bad?
I mean to confirm "commit 7140aaf + git cherry-pick bd4aaf8" is OK
and commit 8ae1266 is bad.
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/
[RESEND PATCH v3 00/17] staging: sm750fb: coding style fixes
Hi,
These patches are fixing coding style issues in ddk750_*i2c* files of the
sm750fb driver
v3 changes:
* fix wrong variable rename in patch 12 (staging: sm750fb: ddk750_swi2c:
staticize swI2C{SCL,SDA})
* fix changelong text in patch 9 (staging: sm750fb: ddk750_swi2c: staticize
swI2C{SCL,SDA})
v2 changes:
* add changelog text
* change patch 5 (staging: sm750fb: ddk750_hwi2c: rename CamelCase static
functions) so that ut won't add sm750_ prefix to static functions
Mike Rapoport (17):
staging: sm750fb: rename hwI2CInit to sm750_hw_i2c_init
staging: sm750fb: rename hwI2CClose to sm750_hw_i2c_close
staging: sm750fb: rename hwI2CReadReg to sm750_hw_i2c_read_reg
staging: sm750fb: rename hwI2CWriteReg to sm750_hw_i2c_write_reg
staging: sm750fb: ddk750_hwi2c: rename CamelCase static functions
staging: sm750fb: rename swI2CInit to sm750_sw_i2c_init
staging: sm750fb: rename swI2CReadReg to sm750_sw_i2c_read_reg
staging: sm750fb: rename swI2CWriteReg to sm750_sw_i2c_write_reg
staging: sm750fb: ddk750_swi2c: staticize swI2C{SCL,SDA}
staging: sm750fb: ddk750_swi2c: rename CamelCase static functions
staging: sm750fb: ddk750_hw_i2c: rename busSpeedMode
staging: sm750fb: hw_i2c_{read,write}: rename CamelCase variables
staging: sm750fb: ddk750_hwi2c: reduce amount of CamelCase
staging: sm750fb: ddk750_swi2c: rename CamelCase static variables
staging: sm750fb: ddk750_swi2c: further reduce CamelCase
staging: sm750fb: ddk750_*i2c: remove multiple blank lines
staging: sm750fb: ddk750_*i2c: shorten lines to under 80 characters
drivers/staging/sm750fb/ddk750_hwi2c.c | 109 ++--
drivers/staging/sm750fb/ddk750_hwi2c.h | 9 +-
drivers/staging/sm750fb/ddk750_sii164.c | 8 +-
drivers/staging/sm750fb/ddk750_swi2c.c | 291
drivers/staging/sm750fb/ddk750_swi2c.h | 47 ++
drivers/staging/sm750fb/sm750_hw.c | 10 +-
6 files changed, 228 insertions(+), 246 deletions(-)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 01/17] staging: sm750fb: rename hwI2CInit to sm750_hw_i2c_init
Fix the checkpatch warning about CamelCase
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 2 +-
drivers/staging/sm750fb/ddk750_hwi2c.h | 2 +-
drivers/staging/sm750fb/ddk750_sii164.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 5ddac43..7eb122e 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -9,7 +9,7 @@
#define HWI2C_WAIT_TIMEOUT 0xF
-int hwI2CInit(
+int sm750_hw_i2c_init(
unsigned char busSpeedMode
)
{
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h
b/drivers/staging/sm750fb/ddk750_hwi2c.h
index 0b830ba6..11381eb 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.h
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.h
@@ -2,7 +2,7 @@
#define DDK750_HWI2C_H__
/* hwi2c functions */
-int hwI2CInit(unsigned char busSpeedMode);
+int sm750_hw_i2c_init(unsigned char busSpeedMode);
void hwI2CClose(void);
unsigned char hwI2CReadReg(unsigned char deviceAddress, unsigned char
registerIndex);
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c
b/drivers/staging/sm750fb/ddk750_sii164.c
index 0bdf3db..1803b74 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -130,7 +130,7 @@ long sii164InitChip(
/* Initialize the i2c bus */
#ifdef USE_HW_I2C
/* Use fast mode. */
- hwI2CInit(1);
+ sm750_hw_i2c_init(1);
#else
swI2CInit(DEFAULT_I2C_SCL, DEFAULT_I2C_SDA);
#endif
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] powerpc32: memcpy: only use dcbz once cache is enabled
Le 11/09/2015 23:35, Scott Wood a écrit : On Fri, 2015-09-11 at 16:33 +0200, Christophe Leroy wrote: memcpy() uses instruction dcbz to speed up copy by not wasting time loading cache line with data that will be overwritten. Some platform like mpc52xx do no have cache active at startup and can therefore not use memcpy(). Allthough no part of the code explicitly uses memcpy(), GCC makes calls to it. This patch modifies memcpy() such that at startup, memcpy() unconditionally jumps to generic_memcpy() which doesn't use the dcbz instruction. Once the initial MMU is set up, in machine_init() we patch memcpy() by replacing this inconditional jump by a NOP Reported-by: Michal Sojka Signed-off-by: Christophe Leroy --- changes in v2: Using feature-fixups instead of hardcoded call to patch_instruction() Handling of memset() added changes in v3: Not using anymore feature-fixups Handling of memset() removed Why was handling of memset() removed? Initially, the issue was reported for memcpy() only. v1 was only handling memcpy() When it came to using fixups with v2, it took the opportunity to also handle memset() just in case, as it was quite simple. Now with v3, we are back to using simple solution with patch_instruction() as recommended by Michael, having to point to the instruction to be replaced by a NOP. For memcpy() it is quite easy, we just put a jump to generic_memcpy() as first instruction of memcpy(). For memset() we don't have a generic_memset() to jump to in the begining of memset(). We have to skip the handling of complete cache lines (block starting with "clrlwir7,r6,32-LG_CACHELINE_BYTES"). This means we have to add a global symbol for that to use with patch_instruction() memset() doesn't seem to be an issue for the time being. Should we do it anyway ? Christophe --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 05/17] staging: sm750fb: ddk750_hwi2c: rename CamelCase static functions
Fix the checkpatch warning about CamelCase.
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index e6d31db..65c1546 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -60,7 +60,7 @@ void sm750_hw_i2c_close(void)
}
-static long hwI2CWaitTXDone(void)
+static long hw_i2c_wait_tx_done(void)
{
unsigned int timeout;
@@ -90,7 +90,7 @@ static long hwI2CWaitTXDone(void)
* Return Value:
* Total number of bytes those are actually written.
*/
-static unsigned int hwI2CWriteData(
+static unsigned int hw_i2c_write_data(
unsigned char deviceAddress,
unsigned int length,
unsigned char *pBuffer
@@ -125,7 +125,7 @@ static unsigned int hwI2CWriteData(
POKE32(I2C_CTRL, FIELD_SET(PEEK32(I2C_CTRL), I2C_CTRL, CTRL,
START));
/* Wait until the transfer is completed. */
- if (hwI2CWaitTXDone() != 0)
+ if (hw_i2c_wait_tx_done() != 0)
break;
/* Substract length */
@@ -156,7 +156,7 @@ static unsigned int hwI2CWriteData(
* Return Value:
* Total number of actual bytes read from the slave device
*/
-static unsigned int hwI2CReadData(
+static unsigned int hw_i2c_read_data(
unsigned char deviceAddress,
unsigned int length,
unsigned char *pBuffer
@@ -187,7 +187,7 @@ static unsigned int hwI2CReadData(
POKE32(I2C_CTRL, FIELD_SET(PEEK32(I2C_CTRL), I2C_CTRL, CTRL,
START));
/* Wait until transaction done. */
- if (hwI2CWaitTXDone() != 0)
+ if (hw_i2c_wait_tx_done() != 0)
break;
/* Save the data to the given buffer */
@@ -226,8 +226,8 @@ unsigned char sm750_hw_i2c_read_reg(
{
unsigned char value = (0xFF);
- if (hwI2CWriteData(deviceAddress, 1, ®isterIndex) == 1)
- hwI2CReadData(deviceAddress, 1, &value);
+ if (hw_i2c_write_data(deviceAddress, 1, ®isterIndex) == 1)
+ hw_i2c_read_data(deviceAddress, 1, &value);
return value;
}
@@ -259,7 +259,7 @@ int sm750_hw_i2c_write_reg(
value[0] = registerIndex;
value[1] = data;
- if (hwI2CWriteData(deviceAddress, 2, value) == 2)
+ if (hw_i2c_write_data(deviceAddress, 2, value) == 2)
return 0;
return (-1);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 03/17] staging: sm750fb: rename hwI2CReadReg to sm750_hw_i2c_read_reg
Fix the checkpatch warning about CamelCase Signed-off-by: Mike Rapoport --- drivers/staging/sm750fb/ddk750_hwi2c.c | 2 +- drivers/staging/sm750fb/ddk750_hwi2c.h | 2 +- drivers/staging/sm750fb/ddk750_sii164.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c b/drivers/staging/sm750fb/ddk750_hwi2c.c index 8aa83ab..03da0a7 100644 --- a/drivers/staging/sm750fb/ddk750_hwi2c.c +++ b/drivers/staging/sm750fb/ddk750_hwi2c.c @@ -219,7 +219,7 @@ static unsigned int hwI2CReadData( * Return Value: * Register value */ -unsigned char hwI2CReadReg( +unsigned char sm750_hw_i2c_read_reg( unsigned char deviceAddress, unsigned char registerIndex ) diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h b/drivers/staging/sm750fb/ddk750_hwi2c.h index a8d23d2..70a6007 100644 --- a/drivers/staging/sm750fb/ddk750_hwi2c.h +++ b/drivers/staging/sm750fb/ddk750_hwi2c.h @@ -5,6 +5,6 @@ int sm750_hw_i2c_init(unsigned char busSpeedMode); void sm750_hw_i2c_close(void); -unsigned char hwI2CReadReg(unsigned char deviceAddress, unsigned char registerIndex); +unsigned char sm750_hw_i2c_read_reg(unsigned char deviceAddress, unsigned char registerIndex); int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex, unsigned char data); #endif diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c index 1803b74..20dbc05 100644 --- a/drivers/staging/sm750fb/ddk750_sii164.c +++ b/drivers/staging/sm750fb/ddk750_sii164.c @@ -12,7 +12,7 @@ #ifdef USE_HW_I2C #define i2cWriteReg hwI2CWriteReg -#define i2cReadReg hwI2CReadReg +#define i2cReadReg sm750_hw_i2c_read_reg #else #define i2cWriteReg swI2CWriteReg #define i2cReadReg swI2CReadReg -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 12/17] staging: sm750fb: hw_i2c_{read,write}: rename CamelCase variables
Rename longCamelCase variables deviceAddress and registerIndex to
shorter addr and reg
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 16
drivers/staging/sm750fb/ddk750_hwi2c.h | 4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index a35505d..abac6ae 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -220,14 +220,14 @@ static unsigned int hw_i2c_read_data(
* Register value
*/
unsigned char sm750_hw_i2c_read_reg(
- unsigned char deviceAddress,
- unsigned char registerIndex
+ unsigned char addr,
+ unsigned char reg
)
{
unsigned char value = (0xFF);
- if (hw_i2c_write_data(deviceAddress, 1, ®isterIndex) == 1)
- hw_i2c_read_data(deviceAddress, 1, &value);
+ if (hw_i2c_write_data(addr, 1, ®) == 1)
+ hw_i2c_read_data(addr, 1, &value);
return value;
}
@@ -250,16 +250,16 @@ unsigned char sm750_hw_i2c_read_reg(
* -1 - Fail
*/
int sm750_hw_i2c_write_reg(
- unsigned char deviceAddress,
- unsigned char registerIndex,
+ unsigned char addr,
+ unsigned char reg,
unsigned char data
)
{
unsigned char value[2];
- value[0] = registerIndex;
+ value[0] = reg;
value[1] = data;
- if (hw_i2c_write_data(deviceAddress, 2, value) == 2)
+ if (hw_i2c_write_data(addr, 2, value) == 2)
return 0;
return (-1);
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h
b/drivers/staging/sm750fb/ddk750_hwi2c.h
index 5872f9c..2827865 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.h
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.h
@@ -5,6 +5,6 @@
int sm750_hw_i2c_init(unsigned char bus_speed_mode);
void sm750_hw_i2c_close(void);
-unsigned char sm750_hw_i2c_read_reg(unsigned char deviceAddress, unsigned char
registerIndex);
-int sm750_hw_i2c_write_reg(unsigned char deviceAddress, unsigned char
registerIndex, unsigned char data);
+unsigned char sm750_hw_i2c_read_reg(unsigned char addr, unsigned char reg);
+int sm750_hw_i2c_write_reg(unsigned char addr, unsigned char reg, unsigned
char data);
#endif
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 14/17] staging: sm750fb: ddk750_swi2c: rename CamelCase static variables
Rename static variables defining I2C GPIO pins and their control registers from
CamelCase.
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_swi2c.c | 96 +-
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index faaf858..1d7e8f6 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -55,8 +55,8 @@
**/
/* GPIO pins used for this I2C. It ranges from 0 to 63. */
-static unsigned char g_i2cClockGPIO = DEFAULT_I2C_SCL;
-static unsigned char g_i2cDataGPIO = DEFAULT_I2C_SDA;
+static unsigned char sw_i2c_clk_gpio = DEFAULT_I2C_SCL;
+static unsigned char sw_i2c_data_gpio = DEFAULT_I2C_SDA;
/*
* Below is the variable declaration for the GPIO pin register usage
@@ -70,14 +70,14 @@ static unsigned char g_i2cDataGPIO = DEFAULT_I2C_SDA;
*/
/* i2c Clock GPIO Register usage */
-static unsigned long g_i2cClkGPIOMuxReg = GPIO_MUX;
-static unsigned long g_i2cClkGPIODataReg = GPIO_DATA;
-static unsigned long g_i2cClkGPIODataDirReg = GPIO_DATA_DIRECTION;
+static unsigned long sw_i2c_clk_gpio_mux_reg = GPIO_MUX;
+static unsigned long sw_i2c_clk_gpio_data_reg = GPIO_DATA;
+static unsigned long sw_i2c_clk_gpio_data_dir_reg = GPIO_DATA_DIRECTION;
/* i2c Data GPIO Register usage */
-static unsigned long g_i2cDataGPIOMuxReg = GPIO_MUX;
-static unsigned long g_i2cDataGPIODataReg = GPIO_DATA;
-static unsigned long g_i2cDataGPIODataDirReg = GPIO_DATA_DIRECTION;
+static unsigned long sw_i2c_data_gpio_mux_reg = GPIO_MUX;
+static unsigned long sw_i2c_data_gpio_data_reg = GPIO_DATA;
+static unsigned long sw_i2c_data_gpio_data_dir_reg = GPIO_DATA_DIRECTION;
/*
* This function puts a delay between command
@@ -124,20 +124,20 @@ static void sw_i2c_scl(unsigned char value)
unsigned long ulGPIOData;
unsigned long ulGPIODirection;
- ulGPIODirection = PEEK32(g_i2cClkGPIODataDirReg);
+ ulGPIODirection = PEEK32(sw_i2c_clk_gpio_data_dir_reg);
if (value) {/* High */
/* Set direction as input. This will automatically pull the
signal up. */
- ulGPIODirection &= ~(1 << g_i2cClockGPIO);
- POKE32(g_i2cClkGPIODataDirReg, ulGPIODirection);
+ ulGPIODirection &= ~(1 << sw_i2c_clk_gpio);
+ POKE32(sw_i2c_clk_gpio_data_dir_reg, ulGPIODirection);
} else {/* Low */
/* Set the signal down */
- ulGPIOData = PEEK32(g_i2cClkGPIODataReg);
- ulGPIOData &= ~(1 << g_i2cClockGPIO);
- POKE32(g_i2cClkGPIODataReg, ulGPIOData);
+ ulGPIOData = PEEK32(sw_i2c_clk_gpio_data_reg);
+ ulGPIOData &= ~(1 << sw_i2c_clk_gpio);
+ POKE32(sw_i2c_clk_gpio_data_reg, ulGPIOData);
/* Set direction as output */
- ulGPIODirection |= (1 << g_i2cClockGPIO);
- POKE32(g_i2cClkGPIODataDirReg, ulGPIODirection);
+ ulGPIODirection |= (1 << sw_i2c_clk_gpio);
+ POKE32(sw_i2c_clk_gpio_data_dir_reg, ulGPIODirection);
}
}
@@ -158,20 +158,20 @@ static void sw_i2c_sda(unsigned char value)
unsigned long ulGPIOData;
unsigned long ulGPIODirection;
- ulGPIODirection = PEEK32(g_i2cDataGPIODataDirReg);
+ ulGPIODirection = PEEK32(sw_i2c_data_gpio_data_dir_reg);
if (value) {/* High */
/* Set direction as input. This will automatically pull the
signal up. */
- ulGPIODirection &= ~(1 << g_i2cDataGPIO);
- POKE32(g_i2cDataGPIODataDirReg, ulGPIODirection);
+ ulGPIODirection &= ~(1 << sw_i2c_data_gpio);
+ POKE32(sw_i2c_data_gpio_data_dir_reg, ulGPIODirection);
} else {/* Low */
/* Set the signal down */
- ulGPIOData = PEEK32(g_i2cDataGPIODataReg);
- ulGPIOData &= ~(1 << g_i2cDataGPIO);
- POKE32(g_i2cDataGPIODataReg, ulGPIOData);
+ ulGPIOData = PEEK32(sw_i2c_data_gpio_data_reg);
+ ulGPIOData &= ~(1 << sw_i2c_data_gpio);
+ POKE32(sw_i2c_data_gpio_data_reg, ulGPIOData);
/* Set direction as output */
- ulGPIODirection |= (1 << g_i2cDataGPIO);
- POKE32(g_i2cDataGPIODataDirReg, ulGPIODirection);
+ ulGPIODirection |= (1 << sw_i2c_data_gpio);
+ POKE32(sw_i2c_data_gpio_data_dir_reg, ulGPIODirection);
}
}
@@ -187,15 +187,15 @@ static unsigned char sw_i2c_read_sda(void)
unsigned long ulGPIOData;
/* Make sure that the direction is input (High) */
- ulGPIODirection = PEEK32(g_i2cDataGPIODataDirReg);
- if ((ulGPIODirection & (1 << g_i2cDataGPIO)) != (~(1 <<
g_i2cDataGPIO))) {
- ulGPIODirection &= ~(1
[RESEND PATCH v3 16/17] staging: sm750fb: ddk750_*i2c: remove multiple blank lines
Fix the checkpatch warning about multiple blank lines
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 16
drivers/staging/sm750fb/ddk750_swi2c.c | 1 -
2 files changed, 17 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 8d06f48..34b687b 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -8,7 +8,6 @@
#define MAX_HWI2C_FIFO 16
#define HWI2C_WAIT_TIMEOUT 0xF
-
int sm750_hw_i2c_init(
unsigned char bus_speed_mode
)
@@ -39,7 +38,6 @@ unsigned char bus_speed_mode
return 0;
}
-
void sm750_hw_i2c_close(void)
{
unsigned int value;
@@ -59,7 +57,6 @@ void sm750_hw_i2c_close(void)
POKE32(GPIO_MUX, value);
}
-
static long hw_i2c_wait_tx_done(void)
{
unsigned int timeout;
@@ -76,8 +73,6 @@ static long hw_i2c_wait_tx_done(void)
return 0;
}
-
-
/*
* This function writes data to the i2c slave device registers.
*
@@ -139,9 +134,6 @@ static unsigned int hw_i2c_write_data(
return total_bytes;
}
-
-
-
/*
* This function reads data from the slave device and stores them
* in the given buffer
@@ -205,9 +197,6 @@ static unsigned int hw_i2c_read_data(
return total_bytes;
}
-
-
-
/*
* This function reads the slave device's register
*
@@ -232,10 +221,6 @@ unsigned char sm750_hw_i2c_read_reg(
return value;
}
-
-
-
-
/*
* This function writes a value to the slave device's register
*
@@ -265,5 +250,4 @@ int sm750_hw_i2c_write_reg(
return (-1);
}
-
#endif
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index 5cb1cf2..ddbbeff 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -15,7 +15,6 @@
#include "ddk750_swi2c.h"
#include "ddk750_power.h"
-
/***
* I2C Software Master Driver:
* ===
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 10/17] staging: sm750fb: ddk750_swi2c: rename CamelCase static functions
Fix the checkpatch warning about CamelCase.
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_swi2c.c | 116 -
1 file changed, 58 insertions(+), 58 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index 6a10ae3..faaf858 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -82,7 +82,7 @@ static unsigned long g_i2cDataGPIODataDirReg =
GPIO_DATA_DIRECTION;
/*
* This function puts a delay between command
*/
-static void swI2CWait(void)
+static void sw_i2c_wait(void)
{
/* find a bug:
* peekIO method works well before suspend/resume
@@ -119,7 +119,7 @@ static void swI2CWait(void)
* signal because the i2c will fail when other device try to drive the
* signal due to SM50x will drive the signal to always high.
*/
-static void swI2CSCL(unsigned char value)
+static void sw_i2c_scl(unsigned char value)
{
unsigned long ulGPIOData;
unsigned long ulGPIODirection;
@@ -153,7 +153,7 @@ static void swI2CSCL(unsigned char value)
* signal because the i2c will fail when other device try to drive the
* signal due to SM50x will drive the signal to always high.
*/
-static void swI2CSDA(unsigned char value)
+static void sw_i2c_sda(unsigned char value)
{
unsigned long ulGPIOData;
unsigned long ulGPIODirection;
@@ -181,7 +181,7 @@ static void swI2CSDA(unsigned char value)
* Return Value:
* The SDA data bit sent by the Slave
*/
-static unsigned char swI2CReadSDA(void)
+static unsigned char sw_i2c_read_sda(void)
{
unsigned long ulGPIODirection;
unsigned long ulGPIOData;
@@ -204,7 +204,7 @@ static unsigned char swI2CReadSDA(void)
/*
* This function sends ACK signal
*/
-static void swI2CAck(void)
+static void sw_i2c_ack(void)
{
return; /* Single byte read is ok without it. */
}
@@ -212,23 +212,23 @@ static void swI2CAck(void)
/*
* This function sends the start command to the slave device
*/
-static void swI2CStart(void)
+static void sw_i2c_start(void)
{
/* Start I2C */
- swI2CSDA(1);
- swI2CSCL(1);
- swI2CSDA(0);
+ sw_i2c_sda(1);
+ sw_i2c_scl(1);
+ sw_i2c_sda(0);
}
/*
* This function sends the stop command to the slave device
*/
-static void swI2CStop(void)
+static void sw_i2c_stop(void)
{
/* Stop the I2C */
- swI2CSCL(1);
- swI2CSDA(0);
- swI2CSDA(1);
+ sw_i2c_scl(1);
+ sw_i2c_sda(0);
+ sw_i2c_sda(1);
}
/*
@@ -241,7 +241,7 @@ static void swI2CStop(void)
* 0 - Success
* -1 - Fail to write byte
*/
-static long swI2CWriteByte(unsigned char data)
+static long sw_i2c_write_byte(unsigned char data)
{
unsigned char value = data;
int i;
@@ -249,47 +249,47 @@ static long swI2CWriteByte(unsigned char data)
/* Sending the data bit by bit */
for (i = 0; i < 8; i++) {
/* Set SCL to low */
- swI2CSCL(0);
+ sw_i2c_scl(0);
/* Send data bit */
if ((value & 0x80) != 0)
- swI2CSDA(1);
+ sw_i2c_sda(1);
else
- swI2CSDA(0);
+ sw_i2c_sda(0);
- swI2CWait();
+ sw_i2c_wait();
/* Toggle clk line to one */
- swI2CSCL(1);
- swI2CWait();
+ sw_i2c_scl(1);
+ sw_i2c_wait();
/* Shift byte to be sent */
value = value << 1;
}
/* Set the SCL Low and SDA High (prepare to get input) */
- swI2CSCL(0);
- swI2CSDA(1);
+ sw_i2c_scl(0);
+ sw_i2c_sda(1);
/* Set the SCL High for ack */
- swI2CWait();
- swI2CSCL(1);
- swI2CWait();
+ sw_i2c_wait();
+ sw_i2c_scl(1);
+ sw_i2c_wait();
/* Read SDA, until SDA==0 */
for (i = 0; i < 0xff; i++) {
- if (!swI2CReadSDA())
+ if (!sw_i2c_read_sda())
break;
- swI2CSCL(0);
- swI2CWait();
- swI2CSCL(1);
- swI2CWait();
+ sw_i2c_scl(0);
+ sw_i2c_wait();
+ sw_i2c_scl(1);
+ sw_i2c_wait();
}
/* Set the SCL Low and SDA High */
- swI2CSCL(0);
- swI2CSDA(1);
+ sw_i2c_scl(0);
+ sw_i2c_sda(1);
if (i < 0xff)
return 0;
@@ -307,31 +307,31 @@ static long swI2CWriteByte(unsigned char data)
* Return Value:
* One byte data read from the Slave device
*/
-static unsigned char swI2CReadByte(unsigned char ack)
+static unsigned char sw_i2c_read_byte(unsigned char ack)
{
int i;
unsigned char data = 0;
for (i = 7; i >= 0; i--) {
Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256
On Fri, Sep 11, 2015 at 01:10:27PM -0700, Tim Chen wrote: > > Mmmm..., this is a restructuring of the algorithms within > the glue code into multiple drivers instead of one and exposing > them all. It is a bit orthogonal to the intention of this > patch set. I think it is better that I create a > separate patch on the glue code on top of this patch set > to implement this. > > Herbert, do you agree with this approach? Yes I think we can work on the individual crypto registration separately from this patch-set. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 17/17] staging: sm750fb: ddk750_*i2c: shorten lines to under 80 characters
Fix some checkpatch warnings about long lines
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 19 ++-
drivers/staging/sm750fb/ddk750_hwi2c.h | 3 ++-
drivers/staging/sm750fb/ddk750_swi2c.c | 22 --
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 34b687b..7be2111 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -63,7 +63,8 @@ static long hw_i2c_wait_tx_done(void)
/* Wait until the transfer is completed. */
timeout = HWI2C_WAIT_TIMEOUT;
- while ((FIELD_GET(PEEK32(I2C_STATUS), I2C_STATUS, TX) !=
I2C_STATUS_TX_COMPLETED) &&
+ while ((FIELD_GET(PEEK32(I2C_STATUS),
+ I2C_STATUS, TX) != I2C_STATUS_TX_COMPLETED) &&
(timeout != 0))
timeout--;
@@ -102,7 +103,10 @@ static unsigned int hw_i2c_write_data(
* Only 16 byte can be accessed per i2c start instruction.
*/
do {
- /* Reset I2C by writing 0 to I2C_RESET register to clear the
previous status. */
+ /*
+* Reset I2C by writing 0 to I2C_RESET register to
+* clear the previous status.
+*/
POKE32(I2C_RESET, 0);
/* Set the number of bytes to be written */
@@ -117,7 +121,8 @@ static unsigned int hw_i2c_write_data(
POKE32(I2C_DATA0 + i, *buf++);
/* Start the I2C */
- POKE32(I2C_CTRL, FIELD_SET(PEEK32(I2C_CTRL), I2C_CTRL, CTRL,
START));
+ POKE32(I2C_CTRL,
+ FIELD_SET(PEEK32(I2C_CTRL), I2C_CTRL, CTRL, START));
/* Wait until the transfer is completed. */
if (hw_i2c_wait_tx_done() != 0)
@@ -165,7 +170,10 @@ static unsigned int hw_i2c_read_data(
* Only 16 byte can be accessed per i2c start instruction.
*/
do {
- /* Reset I2C by writing 0 to I2C_RESET register to clear all
the status. */
+ /*
+* Reset I2C by writing 0 to I2C_RESET register to
+* clear all the status.
+*/
POKE32(I2C_RESET, 0);
/* Set the number of bytes to be read */
@@ -176,7 +184,8 @@ static unsigned int hw_i2c_read_data(
POKE32(I2C_BYTE_COUNT, count);
/* Start the I2C */
- POKE32(I2C_CTRL, FIELD_SET(PEEK32(I2C_CTRL), I2C_CTRL, CTRL,
START));
+ POKE32(I2C_CTRL,
+ FIELD_SET(PEEK32(I2C_CTRL), I2C_CTRL, CTRL, START));
/* Wait until transaction done. */
if (hw_i2c_wait_tx_done() != 0)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h
b/drivers/staging/sm750fb/ddk750_hwi2c.h
index 2827865..46e22dc 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.h
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.h
@@ -6,5 +6,6 @@ int sm750_hw_i2c_init(unsigned char bus_speed_mode);
void sm750_hw_i2c_close(void);
unsigned char sm750_hw_i2c_read_reg(unsigned char addr, unsigned char reg);
-int sm750_hw_i2c_write_reg(unsigned char addr, unsigned char reg, unsigned
char data);
+int sm750_hw_i2c_write_reg(unsigned char addr, unsigned char reg,
+ unsigned char data);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index ddbbeff..37cdd5b 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -125,7 +125,10 @@ static void sw_i2c_scl(unsigned char value)
gpio_dir = PEEK32(sw_i2c_clk_gpio_data_dir_reg);
if (value) {/* High */
- /* Set direction as input. This will automatically pull the
signal up. */
+ /*
+* Set direction as input. This will automatically
+* pull the signal up.
+*/
gpio_dir &= ~(1 << sw_i2c_clk_gpio);
POKE32(sw_i2c_clk_gpio_data_dir_reg, gpio_dir);
} else {/* Low */
@@ -159,7 +162,10 @@ static void sw_i2c_sda(unsigned char value)
gpio_dir = PEEK32(sw_i2c_data_gpio_data_dir_reg);
if (value) {/* High */
- /* Set direction as input. This will automatically pull the
signal up. */
+ /*
+* Set direction as input. This will automatically
+* pull the signal up.
+*/
gpio_dir &= ~(1 << sw_i2c_data_gpio);
POKE32(sw_i2c_data_gpio_data_dir_reg, gpio_dir);
} else {/* Low */
@@ -184,10 +190,11 @@ static unsigned char sw_i2c_read_sda(void)
{
unsigned long gpio_dir;
unsigned long gpio_data;
+ unsigned long dir_mask = 1 << sw_i2c_data_gpio;
/* Make sure that the direction is i
Re: [RFC][PATCH 2/3] perf: Fix u16 overflows
* Peter Zijlstra wrote: > Vince reported that its possible to overflow the various size fields > and get weird stuff if you stick too many events in a group. > > Put a lid on this by requiring the fixed record size not exceed 16k. > This is still a fair amount of events (silly amount really) and leaves > plenty room for callchains and stack dwarves while also avoiding > overflowing the u16 variables. Does this leave a natural ABI extension route here, in case in the future it becomes a problem? We should take aside a value to mean 'larger record' or such? Could we list exactly which fields this concerns, in which structures? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 13/17] staging: sm750fb: ddk750_hwi2c: reduce amount of CamelCase
Rename camel case variables deviceAddress, pBuffer and totalBytes to
addr, buf and total_bytes respectively in sm750_hw_i2c_{read,write}_data
functions.
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 36 +-
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index abac6ae..8d06f48 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -82,25 +82,25 @@ static long hw_i2c_wait_tx_done(void)
* This function writes data to the i2c slave device registers.
*
* Parameters:
- * deviceAddress - i2c Slave device address
+ * addr- i2c Slave device address
* length - Total number of bytes to be written to the device
- * pBuffer - The buffer that contains the data to be written to
the
+ * buf - The buffer that contains the data to be written to
the
* i2c device.
*
* Return Value:
* Total number of bytes those are actually written.
*/
static unsigned int hw_i2c_write_data(
- unsigned char deviceAddress,
+ unsigned char addr,
unsigned int length,
- unsigned char *pBuffer
+ unsigned char *buf
)
{
unsigned char count, i;
- unsigned int totalBytes = 0;
+ unsigned int total_bytes = 0;
/* Set the Device Address */
- POKE32(I2C_SLAVE_ADDRESS, deviceAddress & ~0x01);
+ POKE32(I2C_SLAVE_ADDRESS, addr & ~0x01);
/* Write data.
* Note:
@@ -119,7 +119,7 @@ static unsigned int hw_i2c_write_data(
/* Move the data to the I2C data register */
for (i = 0; i <= count; i++)
- POKE32(I2C_DATA0 + i, *pBuffer++);
+ POKE32(I2C_DATA0 + i, *buf++);
/* Start the I2C */
POKE32(I2C_CTRL, FIELD_SET(PEEK32(I2C_CTRL), I2C_CTRL, CTRL,
START));
@@ -132,11 +132,11 @@ static unsigned int hw_i2c_write_data(
length -= (count + 1);
/* Total byte written */
- totalBytes += (count + 1);
+ total_bytes += (count + 1);
} while (length > 0);
- return totalBytes;
+ return total_bytes;
}
@@ -147,9 +147,9 @@ static unsigned int hw_i2c_write_data(
* in the given buffer
*
* Parameters:
- * deviceAddress - i2c Slave device address
+ * addr- i2c Slave device address
* length - Total number of bytes to be read
- * pBuffer - Pointer to a buffer to be filled with the data read
+ * buf - Pointer to a buffer to be filled with the data read
* from the slave device. It has to be the same size as the
* length to make sure that it can keep all the data read.
*
@@ -157,16 +157,16 @@ static unsigned int hw_i2c_write_data(
* Total number of actual bytes read from the slave device
*/
static unsigned int hw_i2c_read_data(
- unsigned char deviceAddress,
+ unsigned char addr,
unsigned int length,
- unsigned char *pBuffer
+ unsigned char *buf
)
{
unsigned char count, i;
- unsigned int totalBytes = 0;
+ unsigned int total_bytes = 0;
/* Set the Device Address */
- POKE32(I2C_SLAVE_ADDRESS, deviceAddress | 0x01);
+ POKE32(I2C_SLAVE_ADDRESS, addr | 0x01);
/* Read data and save them to the buffer.
* Note:
@@ -192,17 +192,17 @@ static unsigned int hw_i2c_read_data(
/* Save the data to the given buffer */
for (i = 0; i <= count; i++)
- *pBuffer++ = PEEK32(I2C_DATA0 + i);
+ *buf++ = PEEK32(I2C_DATA0 + i);
/* Substract length by 16 */
length -= (count + 1);
/* Number of bytes read. */
- totalBytes += (count + 1);
+ total_bytes += (count + 1);
} while (length > 0);
- return totalBytes;
+ return total_bytes;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 15/17] staging: sm750fb: ddk750_swi2c: further reduce CamelCase
Rename remaining CamelCase variables
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_swi2c.c | 122 -
drivers/staging/sm750fb/ddk750_swi2c.h | 20 +++---
2 files changed, 71 insertions(+), 71 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index 1d7e8f6..5cb1cf2 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -98,11 +98,11 @@ static void sw_i2c_wait(void)
*/
while (peekIO(0x3ce, 0x61) & 0x10);
#else
- int i, Temp;
+ int i, tmp;
for (i = 0; i < 600; i++) {
- Temp = i;
- Temp += i;
+ tmp = i;
+ tmp += i;
}
#endif
}
@@ -121,23 +121,23 @@ static void sw_i2c_wait(void)
*/
static void sw_i2c_scl(unsigned char value)
{
- unsigned long ulGPIOData;
- unsigned long ulGPIODirection;
+ unsigned long gpio_data;
+ unsigned long gpio_dir;
- ulGPIODirection = PEEK32(sw_i2c_clk_gpio_data_dir_reg);
+ gpio_dir = PEEK32(sw_i2c_clk_gpio_data_dir_reg);
if (value) {/* High */
/* Set direction as input. This will automatically pull the
signal up. */
- ulGPIODirection &= ~(1 << sw_i2c_clk_gpio);
- POKE32(sw_i2c_clk_gpio_data_dir_reg, ulGPIODirection);
+ gpio_dir &= ~(1 << sw_i2c_clk_gpio);
+ POKE32(sw_i2c_clk_gpio_data_dir_reg, gpio_dir);
} else {/* Low */
/* Set the signal down */
- ulGPIOData = PEEK32(sw_i2c_clk_gpio_data_reg);
- ulGPIOData &= ~(1 << sw_i2c_clk_gpio);
- POKE32(sw_i2c_clk_gpio_data_reg, ulGPIOData);
+ gpio_data = PEEK32(sw_i2c_clk_gpio_data_reg);
+ gpio_data &= ~(1 << sw_i2c_clk_gpio);
+ POKE32(sw_i2c_clk_gpio_data_reg, gpio_data);
/* Set direction as output */
- ulGPIODirection |= (1 << sw_i2c_clk_gpio);
- POKE32(sw_i2c_clk_gpio_data_dir_reg, ulGPIODirection);
+ gpio_dir |= (1 << sw_i2c_clk_gpio);
+ POKE32(sw_i2c_clk_gpio_data_dir_reg, gpio_dir);
}
}
@@ -155,23 +155,23 @@ static void sw_i2c_scl(unsigned char value)
*/
static void sw_i2c_sda(unsigned char value)
{
- unsigned long ulGPIOData;
- unsigned long ulGPIODirection;
+ unsigned long gpio_data;
+ unsigned long gpio_dir;
- ulGPIODirection = PEEK32(sw_i2c_data_gpio_data_dir_reg);
+ gpio_dir = PEEK32(sw_i2c_data_gpio_data_dir_reg);
if (value) {/* High */
/* Set direction as input. This will automatically pull the
signal up. */
- ulGPIODirection &= ~(1 << sw_i2c_data_gpio);
- POKE32(sw_i2c_data_gpio_data_dir_reg, ulGPIODirection);
+ gpio_dir &= ~(1 << sw_i2c_data_gpio);
+ POKE32(sw_i2c_data_gpio_data_dir_reg, gpio_dir);
} else {/* Low */
/* Set the signal down */
- ulGPIOData = PEEK32(sw_i2c_data_gpio_data_reg);
- ulGPIOData &= ~(1 << sw_i2c_data_gpio);
- POKE32(sw_i2c_data_gpio_data_reg, ulGPIOData);
+ gpio_data = PEEK32(sw_i2c_data_gpio_data_reg);
+ gpio_data &= ~(1 << sw_i2c_data_gpio);
+ POKE32(sw_i2c_data_gpio_data_reg, gpio_data);
/* Set direction as output */
- ulGPIODirection |= (1 << sw_i2c_data_gpio);
- POKE32(sw_i2c_data_gpio_data_dir_reg, ulGPIODirection);
+ gpio_dir |= (1 << sw_i2c_data_gpio);
+ POKE32(sw_i2c_data_gpio_data_dir_reg, gpio_dir);
}
}
@@ -183,19 +183,19 @@ static void sw_i2c_sda(unsigned char value)
*/
static unsigned char sw_i2c_read_sda(void)
{
- unsigned long ulGPIODirection;
- unsigned long ulGPIOData;
+ unsigned long gpio_dir;
+ unsigned long gpio_data;
/* Make sure that the direction is input (High) */
- ulGPIODirection = PEEK32(sw_i2c_data_gpio_data_dir_reg);
- if ((ulGPIODirection & (1 << sw_i2c_data_gpio)) != (~(1 <<
sw_i2c_data_gpio))) {
- ulGPIODirection &= ~(1 << sw_i2c_data_gpio);
- POKE32(sw_i2c_data_gpio_data_dir_reg, ulGPIODirection);
+ gpio_dir = PEEK32(sw_i2c_data_gpio_data_dir_reg);
+ if ((gpio_dir & (1 << sw_i2c_data_gpio)) != (~(1 << sw_i2c_data_gpio)))
{
+ gpio_dir &= ~(1 << sw_i2c_data_gpio);
+ POKE32(sw_i2c_data_gpio_data_dir_reg, gpio_dir);
}
/* Now read the SDA line */
- ulGPIOData = PEEK32(sw_i2c_data_gpio_data_reg);
- if (ulGPIOData & (1 << sw_i2c_data_gpio))
+ gpio_data = PEEK32(sw_i2c_data_gpio_data_reg);
+ if (gpio_data & (1 << sw_i2c_data_gpio))
return 1;
else
return 0;
@@ -340,15 +340,15 @@ static
[RESEND PATCH v3 07/17] staging: sm750fb: rename swI2CReadReg to sm750_sw_i2c_read_reg
Fix the checkpatch warning about CamelCase.
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_swi2c.c | 2 +-
drivers/staging/sm750fb/ddk750_swi2c.h | 2 +-
drivers/staging/sm750fb/sm750_hw.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index ecfd300..765edd6 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -443,7 +443,7 @@ long sm750_sw_i2c_init(
* Return Value:
* Register value
*/
-unsigned char swI2CReadReg(
+unsigned char sm750_sw_i2c_read_reg(
unsigned char deviceAddress,
unsigned char registerIndex
)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.h
b/drivers/staging/sm750fb/ddk750_swi2c.h
index 1e18b80..2e87a63 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.h
+++ b/drivers/staging/sm750fb/ddk750_swi2c.h
@@ -44,7 +44,7 @@ long sm750_sw_i2c_init(
* Return Value:
* Register value
*/
-unsigned char swI2CReadReg(
+unsigned char sm750_sw_i2c_read_reg(
unsigned char deviceAddress,
unsigned char registerIndex
);
diff --git a/drivers/staging/sm750fb/sm750_hw.c
b/drivers/staging/sm750fb/sm750_hw.c
index 522736e..b8b5e00 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -175,7 +175,7 @@ int hw_sm750_inithw(struct lynx_share *share, struct
pci_dev *pdev)
/* Customer may NOT use CH7301 DVI chip, which has to be
initialized differently.
*/
- if (swI2CReadReg(0xec, 0x4a) == 0x95) {
+ if (sm750_sw_i2c_read_reg(0xec, 0x4a) == 0x95) {
/* The following register values for CH7301 are from
Chrontel app note and our experiment.
*/
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 08/17] staging: sm750fb: rename swI2CWriteReg to sm750_sw_i2c_write_reg
Fix the checkpatch warning about CamelCase.
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_swi2c.c | 2 +-
drivers/staging/sm750fb/ddk750_swi2c.h | 2 +-
drivers/staging/sm750fb/sm750_hw.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index 765edd6..e3f60eb 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -483,7 +483,7 @@ unsigned char sm750_sw_i2c_read_reg(
* 0 - Success
* -1 - Fail
*/
-long swI2CWriteReg(
+long sm750_sw_i2c_write_reg(
unsigned char deviceAddress,
unsigned char registerIndex,
unsigned char data
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.h
b/drivers/staging/sm750fb/ddk750_swi2c.h
index 2e87a63..37335dd 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.h
+++ b/drivers/staging/sm750fb/ddk750_swi2c.h
@@ -62,7 +62,7 @@ unsigned char sm750_sw_i2c_read_reg(
* 0 - Success
* -1 - Fail
*/
-long swI2CWriteReg(
+long sm750_sw_i2c_write_reg(
unsigned char deviceAddress,
unsigned char registerIndex,
unsigned char data
diff --git a/drivers/staging/sm750fb/sm750_hw.c
b/drivers/staging/sm750fb/sm750_hw.c
index b8b5e00..de30429 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -180,9 +180,9 @@ int hw_sm750_inithw(struct lynx_share *share, struct
pci_dev *pdev)
Chrontel app note and our experiment.
*/
pr_info("yes,CH7301 DVI chip found\n");
- swI2CWriteReg(0xec, 0x1d, 0x16);
- swI2CWriteReg(0xec, 0x21, 0x9);
- swI2CWriteReg(0xec, 0x49, 0xC0);
+ sm750_sw_i2c_write_reg(0xec, 0x1d, 0x16);
+ sm750_sw_i2c_write_reg(0xec, 0x21, 0x9);
+ sm750_sw_i2c_write_reg(0xec, 0x49, 0xC0);
pr_info("okay,CH7301 DVI chip setup done\n");
}
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 11/17] staging: sm750fb: ddk750_hw_i2c: rename busSpeedMode
rename CamelCase parameter in sm750_hw_i2c_init()
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 4 ++--
drivers/staging/sm750fb/ddk750_hwi2c.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 65c1546..a35505d 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -10,7 +10,7 @@
int sm750_hw_i2c_init(
-unsigned char busSpeedMode
+unsigned char bus_speed_mode
)
{
unsigned int value;
@@ -29,7 +29,7 @@ unsigned char busSpeedMode
/* Enable the I2C Controller and set the bus speed mode */
value = PEEK32(I2C_CTRL);
- if (busSpeedMode == 0)
+ if (bus_speed_mode == 0)
value = FIELD_SET(value, I2C_CTRL, MODE, STANDARD);
else
value = FIELD_SET(value, I2C_CTRL, MODE, FAST);
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h
b/drivers/staging/sm750fb/ddk750_hwi2c.h
index 29ce48d..5872f9c 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.h
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.h
@@ -2,7 +2,7 @@
#define DDK750_HWI2C_H__
/* hwi2c functions */
-int sm750_hw_i2c_init(unsigned char busSpeedMode);
+int sm750_hw_i2c_init(unsigned char bus_speed_mode);
void sm750_hw_i2c_close(void);
unsigned char sm750_hw_i2c_read_reg(unsigned char deviceAddress, unsigned char
registerIndex);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 09/17] staging: sm750fb: ddk750_swi2c: staticize swI2C{SCL,SDA}
swI2C{SCL,SDA} are not used outside ddk750_swi2c, make them static
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_swi2c.c | 4 ++--
drivers/staging/sm750fb/ddk750_swi2c.h | 21 -
2 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c
b/drivers/staging/sm750fb/ddk750_swi2c.c
index e3f60eb..6a10ae3 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -119,7 +119,7 @@ static void swI2CWait(void)
* signal because the i2c will fail when other device try to drive the
* signal due to SM50x will drive the signal to always high.
*/
-void swI2CSCL(unsigned char value)
+static void swI2CSCL(unsigned char value)
{
unsigned long ulGPIOData;
unsigned long ulGPIODirection;
@@ -153,7 +153,7 @@ void swI2CSCL(unsigned char value)
* signal because the i2c will fail when other device try to drive the
* signal due to SM50x will drive the signal to always high.
*/
-void swI2CSDA(unsigned char value)
+static void swI2CSDA(unsigned char value)
{
unsigned long ulGPIOData;
unsigned long ulGPIODirection;
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.h
b/drivers/staging/sm750fb/ddk750_swi2c.h
index 37335dd..27a04f3a 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.h
+++ b/drivers/staging/sm750fb/ddk750_swi2c.h
@@ -68,25 +68,4 @@ long sm750_sw_i2c_write_reg(
unsigned char data
);
-/*
- * These two functions toggle the data on the SCL and SDA I2C lines.
- * The use of these two functions is not recommended unless it is necessary.
- */
-
-/*
- * This function set/reset the SCL GPIO pin
- *
- * Parameters:
- * value - Bit value to set to the SCL or SDA (0 = low, 1 = high)
- */
-void swI2CSCL(unsigned char value);
-
-/*
- * This function set/reset the SDA GPIO pin
- *
- * Parameters:
- * value - Bit value to set to the SCL or SDA (0 = low, 1 = high)
- */
-void swI2CSDA(unsigned char value);
-
#endif /* _SWI2C_H_ */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 04/17] staging: sm750fb: rename hwI2CWriteReg to sm750_hw_i2c_write_reg
Fix the checkpatch warning about CamelCase Signed-off-by: Mike Rapoport --- drivers/staging/sm750fb/ddk750_hwi2c.c | 2 +- drivers/staging/sm750fb/ddk750_hwi2c.h | 2 +- drivers/staging/sm750fb/ddk750_sii164.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c b/drivers/staging/sm750fb/ddk750_hwi2c.c index 03da0a7..e6d31db 100644 --- a/drivers/staging/sm750fb/ddk750_hwi2c.c +++ b/drivers/staging/sm750fb/ddk750_hwi2c.c @@ -249,7 +249,7 @@ unsigned char sm750_hw_i2c_read_reg( * 0 - Success * -1 - Fail */ -int hwI2CWriteReg( +int sm750_hw_i2c_write_reg( unsigned char deviceAddress, unsigned char registerIndex, unsigned char data diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h b/drivers/staging/sm750fb/ddk750_hwi2c.h index 70a6007..29ce48d 100644 --- a/drivers/staging/sm750fb/ddk750_hwi2c.h +++ b/drivers/staging/sm750fb/ddk750_hwi2c.h @@ -6,5 +6,5 @@ int sm750_hw_i2c_init(unsigned char busSpeedMode); void sm750_hw_i2c_close(void); unsigned char sm750_hw_i2c_read_reg(unsigned char deviceAddress, unsigned char registerIndex); -int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex, unsigned char data); +int sm750_hw_i2c_write_reg(unsigned char deviceAddress, unsigned char registerIndex, unsigned char data); #endif diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c index 20dbc05..3d129aa 100644 --- a/drivers/staging/sm750fb/ddk750_sii164.c +++ b/drivers/staging/sm750fb/ddk750_sii164.c @@ -11,7 +11,7 @@ #define USE_HW_I2C #ifdef USE_HW_I2C -#define i2cWriteReg hwI2CWriteReg +#define i2cWriteReg sm750_hw_i2c_write_reg #define i2cReadReg sm750_hw_i2c_read_reg #else #define i2cWriteReg swI2CWriteReg -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 02/17] staging: sm750fb: rename hwI2CClose to sm750_hw_i2c_close
Fix the checkpatch warning about CamelCase
Signed-off-by: Mike Rapoport
---
drivers/staging/sm750fb/ddk750_hwi2c.c | 2 +-
drivers/staging/sm750fb/ddk750_hwi2c.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 7eb122e..8aa83ab 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -40,7 +40,7 @@ unsigned char busSpeedMode
}
-void hwI2CClose(void)
+void sm750_hw_i2c_close(void)
{
unsigned int value;
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h
b/drivers/staging/sm750fb/ddk750_hwi2c.h
index 11381eb..a8d23d2 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.h
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.h
@@ -3,7 +3,7 @@
/* hwi2c functions */
int sm750_hw_i2c_init(unsigned char busSpeedMode);
-void hwI2CClose(void);
+void sm750_hw_i2c_close(void);
unsigned char hwI2CReadReg(unsigned char deviceAddress, unsigned char
registerIndex);
int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex,
unsigned char data);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v3 06/17] staging: sm750fb: rename swI2CInit to sm750_sw_i2c_init
Fix the checkpatch warning about CamelCase. Signed-off-by: Mike Rapoport --- drivers/staging/sm750fb/ddk750_sii164.c | 2 +- drivers/staging/sm750fb/ddk750_swi2c.c | 2 +- drivers/staging/sm750fb/ddk750_swi2c.h | 2 +- drivers/staging/sm750fb/sm750_hw.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c index 3d129aa..241b77b 100644 --- a/drivers/staging/sm750fb/ddk750_sii164.c +++ b/drivers/staging/sm750fb/ddk750_sii164.c @@ -132,7 +132,7 @@ long sii164InitChip( /* Use fast mode. */ sm750_hw_i2c_init(1); #else - swI2CInit(DEFAULT_I2C_SCL, DEFAULT_I2C_SDA); + sm750_sw_i2c_init(DEFAULT_I2C_SCL, DEFAULT_I2C_SDA); #endif /* Check if SII164 Chip exists */ diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c index 5133bcc..ecfd300 100644 --- a/drivers/staging/sm750fb/ddk750_swi2c.c +++ b/drivers/staging/sm750fb/ddk750_swi2c.c @@ -386,7 +386,7 @@ static long swI2CInit_SM750LE(unsigned char i2cClkGPIO, * -1 - Fail to initialize the i2c * 0 - Success */ -long swI2CInit( +long sm750_sw_i2c_init( unsigned char i2cClkGPIO, unsigned char i2cDataGPIO ) diff --git a/drivers/staging/sm750fb/ddk750_swi2c.h b/drivers/staging/sm750fb/ddk750_swi2c.h index 4af2b7a..1e18b80 100644 --- a/drivers/staging/sm750fb/ddk750_swi2c.h +++ b/drivers/staging/sm750fb/ddk750_swi2c.h @@ -28,7 +28,7 @@ * -1 - Fail to initialize the i2c * 0 - Success */ -long swI2CInit( +long sm750_sw_i2c_init( unsigned char i2cClkGPIO, unsigned char i2cDataGPIO ); diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c index 7317ba9..522736e 100644 --- a/drivers/staging/sm750fb/sm750_hw.c +++ b/drivers/staging/sm750fb/sm750_hw.c @@ -169,7 +169,7 @@ int hw_sm750_inithw(struct lynx_share *share, struct pci_dev *pdev) /* Set up GPIO for software I2C to program DVI chip in the Xilinx SP605 board, in order to have video signal. */ - swI2CInit(0, 1); + sm750_sw_i2c_init(0, 1); /* Customer may NOT use CH7301 DVI chip, which has to be -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL rcu/urgent] Fix regression from conversion to RCU_LOCKDEP_WARN()
* Paul E. McKenney wrote:
> Hello, Ingo,
>
> This additional series contains a single fix for a regression introduced
> earlier in this merge window:
>
> 1.security/device_cgroup: f78f5b90c4ff ("rcu: Rename
> rcu_lockdep_assert() to RCU_LOCKDEP_WARN()") introduced a
> bug by incorrectly inverting the condition when moving from
> rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). This commit therefore
> fixes the inversion.
>
> This change has been subjected to 0day Test Robot and -next testing,
> and is available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> for-mingo
>
> for you to fetch changes up to dc3a04d551b5d21f1badbb39bfe8e5bc1289b184:
>
> security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition (2015-09-03
> 18:13:10 -0700)
>
>
> Paul E. McKenney (1):
> security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition
>
> security/device_cgroup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Pulled, thanks a lot Paul!
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 00/78] 4.1.7-stable review
On Fri, Sep 11, 2015 at 06:00:43PM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.1.7 release. > There are 78 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Mon Sep 14 00:57:37 UTC 2015. > Anything received after that time might be too late. Compiled and booted on x86_32. No errors in dmesg. cross_compiled with allmodconfig: i386 - pass x86_64 - pass alphacheck - pass arm - pass cris - pass m68k - pass mips - pass powerpc - pass s390 - pass sparc - pass sparc64 - pass tile - pass tilegx - pass xtensa - pass build report at: https://travis-ci.org/sudipm-mukherjee/parport/builds/79960188 regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] usb: phy: isp1301: Export I2C module alias information
The I2C core always reports the MODALIAS uevent as "i2c:
---
Hello,
This is another resend of this patch. The first post was on July 30 [0]
as a part of a set and then the patch was resent again on August 25 [1].
It is a really trivial patch that fixes a bug (module auto loading not
working) so in case that already missed 4.3, I think it's -rc material.
Best regards,
Javier
[0]: https://lkml.org/lkml/2015/7/30/511
[1]: https://lkml.org/lkml/2015/8/25/40
drivers/usb/phy/phy-isp1301.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
index 8a55b37d1a02..db68156568e6 100644
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/usb/phy/phy-isp1301.c
@@ -31,6 +31,7 @@ static const struct i2c_device_id isp1301_id[] = {
{ "isp1301", 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, isp1301_id);
static struct i2c_client *isp1301_i2c_client;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: pxamci: fix card detect threaded interrupt
Change the interrupt flavor of the card detection, from a hard interrupt
to a threaded interrupt. There is no strong requirement for a hard
interrupt.
It fixes the case where the card detection is on a gpio expander, on I2C
for example on zylonite board. In this case, the card detect netsted
interrupt is called from a threaded interrupt. The request_irq() fails,
because a hard irq cannot be a nested interrupt from a threaded
interrupt (set __setup_irq()).
This was tested on zylonite and mioa701 boards.
Signed-off-by: Robert Jarzmik
Cc: Petr Cvek
---
drivers/mmc/host/pxamci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index 1420f29628c7..67c9d1443597 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -814,8 +814,10 @@ static int pxamci_probe(struct platform_device *pdev)
}
gpio_direction_input(gpio_cd);
- ret = request_irq(gpio_to_irq(gpio_cd), pxamci_detect_irq,
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+ ret = request_threaded_irq(gpio_to_irq(gpio_cd), NULL,
+ pxamci_detect_irq,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
+ IRQF_ONESHOT,
"mmc card detect", mmc);
if (ret) {
dev_err(&pdev->dev, "failed to request card detect
IRQ\n");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Staging: iio: Move evgen interrupt generation to irq_work
On 11/09/15 14:59, Cristina Opriceana wrote:
> Enhance interrupt generation in the dummy driver and expand its usage
> by introducing the irq_work infrastructure to trigger an interrupt.
>
> This way, the irq_work_queue() wrapper permits calling both of the top
> half and threaded part from a hard irq context, unlike handle_nested_irq(),
> which only calls the threaded part.
>
> As an outcome, the driver succeeds in simulating real hardware
> interrupts, while keeping the normal interrupt flow.
>
> Signed-off-by: Cristina Opriceana
Looks good to me. Will let this sit on the list for a little while
though to give others plenty of time to comment.
Thanks for doing this, ended up simpler than I thought it would
be which is always nice ;)
Jonathan
> ---
> Changes since v1:
> - keep irq_chip and the normal interrupt flow
> - run top half and threaded part from hardirq context
> - add demo function that registers current timestamp and uses it in the
> threaded interrupt handler
>
> drivers/staging/iio/iio_dummy_evgen.c | 26 +-
> drivers/staging/iio/iio_simple_dummy.h| 1 +
> drivers/staging/iio/iio_simple_dummy_events.c | 19 ++-
> 3 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/iio/iio_dummy_evgen.c
> b/drivers/staging/iio/iio_dummy_evgen.c
> index 6d38854..2bb4350 100644
> --- a/drivers/staging/iio/iio_dummy_evgen.c
> +++ b/drivers/staging/iio/iio_dummy_evgen.c
> @@ -24,9 +24,21 @@
> #include "iio_dummy_evgen.h"
> #include
> #include
> +#include
>
> /* Fiddly bit of faking and irq without hardware */
> #define IIO_EVENTGEN_NO 10
> +
> +/**
> + * struct iio_dummy_handle_irq - helper struct to simulate interrupt
> generation
> + * @work: irq_work used to run handlers from hardirq context
> + * @irq: fake irq line number to trigger an interrupt
> + */
> +struct iio_dummy_handle_irq {
> + struct irq_work work;
> + int irq;
> +};
> +
> /**
> * struct iio_dummy_evgen - evgen state
> * @chip: irq chip we are faking
> @@ -35,6 +47,7 @@
> * @inuse: mask of which irqs are connected
> * @regs: irq regs we are faking
> * @lock: protect the evgen state
> + * @handler: helper for a 'hardware-like' interrupt simulation
> */
> struct iio_dummy_eventgen {
> struct irq_chip chip;
> @@ -43,6 +56,7 @@ struct iio_dummy_eventgen {
> bool inuse[IIO_EVENTGEN_NO];
> struct iio_dummy_regs regs[IIO_EVENTGEN_NO];
> struct mutex lock;
> + struct iio_dummy_handle_irq handler;
> };
>
> /* We can only ever have one instance of this 'device' */
> @@ -67,6 +81,14 @@ static void iio_dummy_event_irqunmask(struct irq_data *d)
> evgen->enabled[d->irq - evgen->base] = true;
> }
>
> +void iio_dummy_work_handler(struct irq_work *work)
> +{
> + struct iio_dummy_handle_irq *irq_handler;
> +
> + irq_handler = container_of(work, struct iio_dummy_handle_irq, work);
> + handle_simple_irq(irq_handler->irq, irq_to_desc(irq_handler->irq));
> +}
> +
> static int iio_dummy_evgen_create(void)
> {
> int ret, i;
> @@ -91,6 +113,7 @@ static int iio_dummy_evgen_create(void)
> IRQ_NOREQUEST | IRQ_NOAUTOEN,
> IRQ_NOPROBE);
> }
> + init_irq_work(&iio_evgen->handler.work, iio_dummy_work_handler);
> mutex_init(&iio_evgen->lock);
> return 0;
> }
> @@ -169,8 +192,9 @@ static ssize_t iio_evgen_poke(struct device *dev,
> iio_evgen->regs[this_attr->address].reg_id = this_attr->address;
> iio_evgen->regs[this_attr->address].reg_data = event;
>
> + iio_evgen->handler.irq = iio_evgen->base + this_attr->address;
> if (iio_evgen->enabled[this_attr->address])
> - handle_nested_irq(iio_evgen->base + this_attr->address);
> + irq_work_queue(&iio_evgen->handler.work);
>
> return len;
> }
> diff --git a/drivers/staging/iio/iio_simple_dummy.h
> b/drivers/staging/iio/iio_simple_dummy.h
> index 8d00224..5c2f4d0 100644
> --- a/drivers/staging/iio/iio_simple_dummy.h
> +++ b/drivers/staging/iio/iio_simple_dummy.h
> @@ -46,6 +46,7 @@ struct iio_dummy_state {
> int event_irq;
> int event_val;
> bool event_en;
> + s64 event_timestamp;
> #endif /* CONFIG_IIO_SIMPLE_DUMMY_EVENTS */
> };
>
> diff --git a/drivers/staging/iio/iio_simple_dummy_events.c
> b/drivers/staging/iio/iio_simple_dummy_events.c
> index 73108ba..bfbf1c5 100644
> --- a/drivers/staging/iio/iio_simple_dummy_events.c
> +++ b/drivers/staging/iio/iio_simple_dummy_events.c
> @@ -153,6 +153,15 @@ int iio_simple_dummy_write_event_value(struct iio_dev
> *indio_dev,
> return 0;
> }
>
> +static irqreturn_t iio_simple_dummy_get_timestamp(int irq, void *private)
> +{
> + struct iio_dev *indio_dev = private;
> + struct iio_dummy_state *st = iio_priv(indio_dev);
> +
> + st->event_timestamp = iio_get_time_ns();
> + return IRQ_HANDLED;
> +}
> +
>
[PATCH v2] Staging: ft1000: ft1000-usb: Use USB API functions rather than constants
Introduce the use of the function usb_endpoint_is_bulk_in().
Signed-off-by: Shraddha Barke
---
Change in v2-
Make commmit message clearer
drivers/staging/ft1000/ft1000-usb/ft1000_usb.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_usb.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_usb.c
index fd255c6..d1ba0b8 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_usb.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_usb.c
@@ -111,17 +111,13 @@ static int ft1000_probe(struct usb_interface *interface,
pr_debug("endpoint %d\n", i);
pr_debug("bEndpointAddress=%x, bmAttributes=%x\n",
endpoint->bEndpointAddress, endpoint->bmAttributes);
- if ((endpoint->bEndpointAddress & USB_DIR_IN)
- && ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
- USB_ENDPOINT_XFER_BULK)) {
+ if (usb_endpoint_is_bulk_in(endpoint)) {
ft1000dev->bulk_in_endpointAddr =
endpoint->bEndpointAddress;
pr_debug("in: %d\n", endpoint->bEndpointAddress);
}
- if (!(endpoint->bEndpointAddress & USB_DIR_IN)
- && ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
- USB_ENDPOINT_XFER_BULK)) {
+ if (usb_endpoint_is_bulk_in(endpoint)) {
ft1000dev->bulk_out_endpointAddr =
endpoint->bEndpointAddress;
pr_debug("out: %d\n", endpoint->bEndpointAddress);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 0/2] block/xen-blkfront: Support non-indirect with 64KB page granularity
Hi Julien, On 09/12/2015 03:31 AM, Julien Grall wrote: > Hi all, > > This is a follow-up on the previous discussion [1] related to guest using 64KB > page granularity not booting with backend using non-indirect grant. > > This has been successly tested on ARM64 with both 64KB and 4KB page > granularity > guests and QEMU as the backend. Indeed QEMU is not supported indirect. > What's the linux kernel page granularity of the backend(dom0) in your test? Did you test if using xen-blkback as the backend? Especially when linux kernel page granularity of dom0 is 4kB while domU is 64KB. Thanks, -Bob > For a summary of the previous discussion see patch #2. > > This series is based on top of my 64KB page granularity support [2]. > > Comments are welcomed. > > Sincerely yours, > > [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01659.html > [2] https://lwn.net/Articles/656797/ > > Cc: Konrad Rzeszutek Wilk > Cc: "Roger Pau Monné" > Cc: Boris Ostrovsky > Cc: David Vrabel > > Julien Grall (2): > block/xen-blkfront: Introduce blkif_ring_get_request > block/xen-blkfront: Handle non-indirect grant with 64KB pages > > drivers/block/xen-blkfront.c | 229 > ++- > 1 file changed, 202 insertions(+), 27 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 4/6] Staging: iio: cdc: Prefer using the BIT macro
On 10/09/15 17:32, Shraddha Barke wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro > > This was done with coccinelle: > @@ int g; @@ > > -(1 << g) > +BIT(g) > > Signed-off-by: Shraddha Barke Something odd happened here as this is only a small proportion of the cases that should be updated in this file. There's one at the bottom of the patch for starters! This driver also uses a lot of cases of 0 shifted to represent the opposite state for a given bit in the register. The effective documentation provided by that is lost if we convert the bit set ones over like this. Might seem odd, but perhaps we need a ZERO(X) macro as well (which is of course always 0) to cover that approach. Jonathan > --- > drivers/staging/iio/cdc/ad7746.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/iio/cdc/ad7746.c > b/drivers/staging/iio/cdc/ad7746.c > index e6e9eaa..10fa372 100644 > --- a/drivers/staging/iio/cdc/ad7746.c > +++ b/drivers/staging/iio/cdc/ad7746.c > @@ -46,10 +46,10 @@ > #define AD7746_REG_VOLT_GAINL18 > > /* Status Register Bit Designations (AD7746_REG_STATUS) */ > -#define AD7746_STATUS_EXCERR (1 << 3) > -#define AD7746_STATUS_RDY(1 << 2) > -#define AD7746_STATUS_RDYVT (1 << 1) > -#define AD7746_STATUS_RDYCAP (1 << 0) > +#define AD7746_STATUS_EXCERR BIT(3) > +#define AD7746_STATUS_RDYBIT(2) > +#define AD7746_STATUS_RDYVT BIT(1) > +#define AD7746_STATUS_RDYCAP BIT(0) > > /* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) > */ > #define AD7746_CAPSETUP_CAPEN(1 << 7) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl: mediatek: Implement wake handler and suspend resume
hi Sudeep:
I test flowlling your blow suggestions,but the system can not be woken.
beacuse,mtk_eint_suspend will mask it.As we know if eint wakeup system
it must be unmasked before enter suspend flow.
e.x
static int __maybe_unused elan_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
struct elan_tp_data *data = i2c_get_clientdata(client);
int ret;
/*
* We are taking the mutex to make sure sysfs operations are
* complete before we attempt to bring the device into low[er]
* power mode.
*/
ret = mutex_lock_interruptible(&data->sysfs_mutex);
if (ret)
return ret;
disable_irq(client->irq);
if (device_may_wakeup(dev)) {
ret = elan_sleep(data);
/* Enable wake from IRQ */
data->irq_wake = (enable_irq_wake(client->irq) == 0);
} else {
ret = elan_disable_power(data);
}
mutex_unlock(&data->sysfs_mutex);
return ret;
}
thanks
Best Regards,
Maoguang
On Wed, 2015-09-09 at 00:50 +0800, Sudeep Holla wrote:
>
> On 08/09/15 10:28, Sudeep Holla wrote:
> >
> >
> > On 06/09/15 11:39, maoguang meng wrote:
> >> On Wed, 2015-09-02 at 14:02 +0800, Daniel Kurtz wrote:
> >>> Hi maoguang,
> >>>
> >>> On Tue, Aug 25, 2015 at 12:27 AM, Sudeep Holla
> >>> wrote:
>
>
> On 14/08/15 09:38, maoguang.m...@mediatek.com wrote:
> >
> > From: Maoguang Meng
> >
> > This patch implement irq_set_wake to get who is wakeup source and
> > setup on suspend resume.
> >
> > Signed-off-by: Maoguang Meng
> >
> >>> [snip]
> >>>
> >>> Can you please respond to Sudeep's questions:
> >>>
> Does this pinmux controller:
>
> 1. Support wake-up configuration ? If not, you need to use
> IRQCHIP_SKIP_SET_WAKE. I don't see any value in writing the
> mask_{set,clear} if the same registers are used for {en,dis}able
> >>
> >> YES.
> >> we can call enable_irq_wake(irq) to config this irq as a wake-up
> >> source.
> >>
> >
> > No that doesn't answer my question. Yes you can always call
> > enable_irq_wake(irq) as along as you have irq_set_wake implemented.
> > But my question was does this pinmux controller support wake-up
> > configuration.
> >
> > IMHO, by looking at the implementation I can confirm *NO*, it doesn't.
> > So please stop copy-pasting the implementation from other drivers.
> > The reason is you operate on the same mask_{set,clear} which you use
> > to {en,dis}able the interrupts which means you don't have to do anything
> > to configure an interrupt as a wakeup source other than just keeping
> > them enabled. Hopefully this clarifies.
> >
>
> 2. Is in always on domain ? If not, you need save/restore only to
> resume back the functionality. Generally we can set
> IRQCHIP_MASK_ON_SUSPEND to ensure non-wake-up interrupts are
> disabled during suspend and re-enabled in resume path. You just
> save/restore raw values without tracking the wake-up source.
> >>
> >> YES.
> >>
> >
> > Again *YES* for what part of my question. If it's always-on, then you
> > don't need this suspend/resume callbacks at all, so I assume the answer
> > is *NO*.
> >
>
> IIUC this pinmux controller, something like below should work.
>
>
> >8
>
> From 7c26992bce047efb66a6ba8d2ffec2b272499df7 Mon Sep 17 00:00:00 2001
> From: Sudeep Holla
> Date: Tue, 8 Sep 2015 17:35:38 +0100
> Subject: [PATCH] pinctrl: mediatek: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
>
> The mediatek pinmux controller doesn't provides any facility to configure
> the wakeup sources. So instead of providing redundant irq_set_wake
> functionality, SKIP_SET_WAKE could be set to it. Also there's no need to
> maintain 2 sets of masks.
>
> This patch enables IRQCHIP_SKIP_SET_WAKE and IRQCHIP_MASK_ON_SUSPEND and
> also removes wake_mask.
>
> Cc: Linus Walleij
> Cc: Matthias Brugger
> Cc: Hongzhou Yang
> Cc: Yingjoe Chen
> Cc: Maoguang Meng
> Cc: Chaotian Jing
> Cc: linux-g...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Sudeep Holla
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 24
> +---
> drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 1 -
> 2 files changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index 7726c6caaf83..d8e194a5bb31 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> @@ -1063,20 +1063,6 @@ static int mtk_eint_set_type(struct irq_data *d,
> return 0;
> }
>
> -static int mtk_eint_irq_set_wake(struct irq_data *d, unsigned int on)
> -{
> - struct mtk_pinctrl *pctl = irq_data_get_irq_chip_data(d);
> - int shift = d->hwirq & 0x1f;
> - int reg = d->hw
Re: [PATCH 1/6] Staging: iio: addac: Prefer using the BIT macro
On 10/09/15 17:30, Shraddha Barke wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro. > > This was done with coccinelle: > > @@ int g; @@ > > -(1 << g) > +BIT(g) > > Signed-off-by: Shraddha Barke Good straight forward cases. Applied to the togreg branch of iio.git. Will be initially pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- > drivers/staging/iio/addac/adt7316.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/staging/iio/addac/adt7316.c > b/drivers/staging/iio/addac/adt7316.c > index 5b11b42..a1dd745 100644 > --- a/drivers/staging/iio/addac/adt7316.c > +++ b/drivers/staging/iio/addac/adt7316.c > @@ -1756,43 +1756,43 @@ static irqreturn_t adt7316_event_handler(int irq, > void *private) > stat1 &= 0x1F; > > time = iio_get_time_ns(); > - if (stat1 & (1 << 0)) > + if (stat1 & BIT(0)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_TEMP, 0, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_RISING), > time); > - if (stat1 & (1 << 1)) > + if (stat1 & BIT(1)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_TEMP, 0, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_FALLING), > time); > - if (stat1 & (1 << 2)) > + if (stat1 & BIT(2)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_TEMP, 1, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_RISING), > time); > - if (stat1 & (1 << 3)) > + if (stat1 & BIT(3)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_TEMP, 1, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_FALLING), > time); > - if (stat1 & (1 << 5)) > + if (stat1 & BIT(5)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 1, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_EITHER), > time); > - if (stat1 & (1 << 6)) > + if (stat1 & BIT(6)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 2, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_EITHER), > time); > - if (stat1 & (1 << 7)) > + if (stat1 & BIT(7)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 3, > IIO_EV_TYPE_THRESH, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc32: memcpy/memset: only use dcbz once cache is enabled
Le 11/09/2015 03:24, Michael Ellerman a écrit : On Thu, 2015-09-10 at 17:05 -0500, Scott Wood wrote: I don't think this duplication is what Michael meant by "the normal cpu feature sections". What else is going to use this very specific infrastructure? Yeah, sorry, I was hoping you could do it with the existing cpu feature mechanism. It looks like the timing doesn't work, ie. you need to patch this stuff in machine_init(), which is later than the regular patching which gets done in early_init(). This is one of the festering differences we have between the 32 and 64-bit initialisation code, ie. on 64-bit we do the patching much later. I've just thought about maybe another alternative. Is there any issue with calling do_feature_fixups() twice for the same features ? If not, we could define a MMU_CACHE_NOW_ON dummy MMU feature, then call again do_feature_fixups() in machine_init() to patch memcpy/memset stuff, something like: In arch/powerpc/include/asm/mmu.h: +#define MMU_CACHE_NOW_ONASM_CONST(0x8000) In arch/powerpc/kernel/setup_32.c: @machine_init() udbg_early_init(); +spec = identify_cpu(0, mfspr(SPRN_PVR)); +do_feature_fixups(spec->mmu_features | MMU_CACHE_NOW_ON, + &__start___mmu_ftr_fixup, + &__stop___mmu_ftr_fixup); /* Do some early initialization based on the flat device tree */ early_init_devtree(__va(dt_ptr)); Christophe --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] Staging: iio: addac: Prefer using the BIT macro
On 10/09/15 17:30, Shraddha Barke wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro. > > This was done with coccinelle: > > @@ int g; @@ > > -(1 << g) > +BIT(g) > > Signed-off-by: Shraddha Barke A small process related point. These are reworked versions of your earlier series. Please make that obvious with a V2 in the patch name. A cover letter explaining what the changes were is also a useful addition. I suspect a lot of reviewers do what I do and work backwards through their email and hence need the indication that there is an earlier thread they should be cross referring to. Thanks, Jonathan > --- > drivers/staging/iio/addac/adt7316.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/staging/iio/addac/adt7316.c > b/drivers/staging/iio/addac/adt7316.c > index 5b11b42..a1dd745 100644 > --- a/drivers/staging/iio/addac/adt7316.c > +++ b/drivers/staging/iio/addac/adt7316.c > @@ -1756,43 +1756,43 @@ static irqreturn_t adt7316_event_handler(int irq, > void *private) > stat1 &= 0x1F; > > time = iio_get_time_ns(); > - if (stat1 & (1 << 0)) > + if (stat1 & BIT(0)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_TEMP, 0, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_RISING), > time); > - if (stat1 & (1 << 1)) > + if (stat1 & BIT(1)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_TEMP, 0, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_FALLING), > time); > - if (stat1 & (1 << 2)) > + if (stat1 & BIT(2)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_TEMP, 1, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_RISING), > time); > - if (stat1 & (1 << 3)) > + if (stat1 & BIT(3)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_TEMP, 1, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_FALLING), > time); > - if (stat1 & (1 << 5)) > + if (stat1 & BIT(5)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 1, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_EITHER), > time); > - if (stat1 & (1 << 6)) > + if (stat1 & BIT(6)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 2, > IIO_EV_TYPE_THRESH, > IIO_EV_DIR_EITHER), > time); > - if (stat1 & (1 << 7)) > + if (stat1 & BIT(7)) > iio_push_event(indio_dev, > IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, 3, > IIO_EV_TYPE_THRESH, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] futex: eliminate cache miss from futex_hash()
* Davidlohr Bueso wrote: > On Wed, 09 Sep 2015, Rasmus Villemoes wrote: > > >futex_hash() references two global variables: the base pointer > >futex_queues and the size of the array futex_hashsize. The latter is > >marked __read_mostly, while the former is not, so they are likely to > >end up very far from each other. This means that futex_hash() is > >likely to encounter two cache misses. > > > >We could mark futex_queues as __read_mostly as well, but that doesn't > >guarantee they'll end up next to each other (and even if they do, they > >may still end up in different cache lines). So put the two variables > >in a small singleton struct with sufficient alignment and mark that as > >__read_mostly. > > This really doesn't have much practical effect -- not even on larger > boxes, where such things matter. For instance, I ran the patch on a > 60-core IvyBridge with 'perf-bench futex', for which futex-hash > particularly benefits in good data layout (ie our current smp alignment). > > http://linux-scalability.org/futex-__futex_data/ > > I think we should leave it as is. But ... given that these are shared-cached values (cached on all CPUs), this change would only be measurable in such a benchmark if the cache footprint of the test is just about to overflow the size of the CPU cache and the one extra cache line would cause cache trashing. That is very unlikely. So such a change seems to make sense unless you can argue that it's _bad_ to move them closer to each other. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING: CPU: 1 PID: 1676 at drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x48f/0x5f0 [drm]()
Again, the problem with the display, the screen (when logging into gnome shell) is flying from right to left and generates oops --- Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208427] WARNING: CPU: 1 PID: 1676 at drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x48f/0x5f0 [drm]() Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208463] Modules linked in: nls_utf8 cifs fscache snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_pcm snd_hwdep snd_seq_midi i915 snd_seq_midi_event snd_rawmidi i2c_algo_bit drm_kms_helper snd_seq syscopyarea sysfillrect sysimgblt snd_timer joydev snd_seq_device fb_sys_fops serio_raw snd drm lpc_ich soundcore video mac_hid coretemp parport_pc ppdev lp parport autofs4 uas usb_storage psmouse ahci libahci pata_acpi 8139too 8139cp Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208468] CPU: 1 PID: 1676 Comm: Xorg Tainted: GW OE 4.2.0-winsoft-x86+ #2 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208470] Hardware name: FUJITSU SIEMENS AMILO Pro Edition V3405/AMILO Pro Edition V3405, BIOS R01-B0E03/20/2007 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208476] e51318ac c14549e8 e51318e0 c10678eb c1a89448 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208481] 0001 068c f8697138 01eb f86887bf 01eb f86887bf f4f50800 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208485] f4f48c78 e51318f0 c10679c2 0009 e5131940 f86887bf Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208486] Call Trace: Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208495] [] dump_stack+0x41/0x59 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208501] [] warn_slowpath_common+0x8b/0xc0 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208525] [] ? drm_atomic_check_only+0x48f/0x5f0 [drm] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208547] [] ? drm_atomic_check_only+0x48f/0x5f0 [drm] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208550] [] warn_slowpath_null+0x22/0x30 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208573] [] drm_atomic_check_only+0x48f/0x5f0 [drm] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208597] [] ? drm_atomic_set_crtc_for_plane+0x6a/0x100 [drm] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208620] [] drm_atomic_commit+0x16/0x60 [drm] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208676] [] intel_get_load_detect_pipe+0x3f2/0x5d0 [i915] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208721] [] intel_tv_detect+0x106/0x600 [i915] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208735] [] drm_helper_probe_single_connector_modes_merge_bits+0x27b/0x4a0 [drm_kms_helper] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208744] [] drm_helper_probe_single_connector_modes+0x17/0x20 [drm_kms_helper] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208755] [] drm_fb_helper_probe_connector_modes.isra.3+0x41/0x60 [drm_kms_helper] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208764] [] drm_fb_helper_hotplug_event+0x57/0xd0 [drm_kms_helper] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208775] [] drm_fb_helper_restore_fbdev_mode_unlocked+0x38/0x50 [drm_kms_helper] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208784] [] drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208822] [] intel_fbdev_set_par+0x15/0x50 [i915] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208828] [] fb_set_var+0x1b9/0x430 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208832] [] ? enqueue_entity+0x3a1/0x1100 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208837] [] fbcon_blank+0x266/0x330 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208843] [] do_unblank_screen+0xa6/0x1c0 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208847] [] complete_change_console+0x51/0xd0 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208850] [] vt_ioctl+0x1055/0x1290 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208868] [] ? drm_dropmaster_ioctl+0x5e/0x90 [drm] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208872] [] ? capable+0x14/0x20 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208879] [] ? inotify_free_event+0xd/0x10 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208897] [] ? drm_setmaster_ioctl+0xf0/0xf0 [drm] Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208900] [] ? complete_change_console+0xd0/0xd0 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208903] [] tty_ioctl+0x39a/0xaf0 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208909] [] ? do_readv_writev+0x117/0x300 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208913] [] ? sock_sendmsg+0x40/0x40 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208916] [] ? no_tty+0x30/0x30 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208919] [] do_vfs_ioctl+0x322/0x540 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208922] [] ? dput+0xb7/0x220 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208925] [] ? __sb_end_write+0x1a/0x20 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208928] [] SyS_ioctl+0x60/0x90 Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208934] [] sysenter_do_call+0x12/0x12 Sep 12 11:30:42 AM
[PATCH v2 1/3] ARM: dts: support Highspeed for rk3188-radxarock
Add cap-sd-highspeed and cap-mmc-highspeed for rk3188-radxarock board to make sd cards running faster. Signed-off-by: Shawn Lin --- Changes in v2: - Add mmc caps for individual board file arch/arm/boot/dts/rk3188-radxarock.dts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts index d2180e5..2f37ea7 100644 --- a/arch/arm/boot/dts/rk3188-radxarock.dts +++ b/arch/arm/boot/dts/rk3188-radxarock.dts @@ -287,7 +287,8 @@ pinctrl-names = "default"; pinctrl-0 = <&sd0_clk>, <&sd0_cmd>, <&sd0_cd>, <&sd0_bus4>; vmmc-supply = <&vcc_sd0>; - + cap-mmc-highspeed; + cap-sd-highspeed; bus-width = <4>; disable-wp; }; -- 2.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] ARM: dts: support Highspeed for rk3066a-rayeager
Add cap-sd-highspeed and cap-mmc-highspeed for rk3066a-rayeager board to make sd cards running faster. Signed-off-by: Shawn Lin --- Changes in v2: None arch/arm/boot/dts/rk3066a-rayeager.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts b/arch/arm/boot/dts/rk3066a-rayeager.dts index e36383c..341c1f8 100644 --- a/arch/arm/boot/dts/rk3066a-rayeager.dts +++ b/arch/arm/boot/dts/rk3066a-rayeager.dts @@ -330,6 +330,8 @@ pinctrl-names = "default"; pinctrl-0 = <&sd0_clk>, <&sd0_cmd>, <&sd0_cd>, <&sd0_bus4>; vmmc-supply = <&vcc_sd>; + cap-mmc-highspeed; + cap-sd-highspeed; status = "okay"; }; -- 2.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] ARM: dts: support Highspeed for rk3066a-bqcurie2
Add cap-sd-highspeed and cap-mmc-highspeed for rk3066a-bqcurie2
board to make sd cards running faster.
Signed-off-by: Shawn Lin
---
Changes in v2: None
arch/arm/boot/dts/rk3066a-bqcurie2.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index c027375..bf09038 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -187,6 +187,8 @@
vmmc-supply = <&vcc_sd0>;
bus-width = <4>;
disable-wp;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
&mmc1 { /* wifi */
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] iio: mma8452: refactor for seperating chip specific data
On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds a struct mma_chip_info to hold data that will remain specific to
> the chip in use. It is provided during probe() and linked in
> struct of_device_id.
>
> Also this suggests that the driver is called "mma8452" and now handles the
> MMA8452Q device, but is not limited to it.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Christoph Muellner
Applied to the togreg branch of iio.git. Initially pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/accel/mma8452.c | 183
>
> 1 file changed, 134 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index b921d84..f28428fa 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #define MMA8452_STATUS 0x00
> #define MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> @@ -74,6 +75,52 @@ struct mma8452_data {
> struct mutex lock;
> u8 ctrl_reg1;
> u8 data_cfg;
> + const struct mma_chip_info *chip_info;
> +};
> +
> +/**
> + * struct mma_chip_info - chip specific data for Freescale's accelerometers
> + * @chip_id: WHO_AM_I register's value
> + * @channels:struct iio_chan_spec matching the
> device's
> + * capabilities
> + * @num_channels:number of channels
> + * @mma_scales: scale factors for converting register
> values
> + * to m/s^2; 3 modes: 2g, 4g, 8g; 2 integers
> + * per mode: m/s^2 and micro m/s^2
> + * @ev_cfg: event config register address
> + * @ev_cfg_ele: latch bit in event config register
> + * @ev_cfg_chan_shift: number of the bit to enable events in X
> + * direction; in event config register
> + * @ev_src: event source register address
> + * @ev_src_xe: bit in event source register that
> indicates
> + * an event in X direction
> + * @ev_src_ye: bit in event source register that
> indicates
> + * an event in Y direction
> + * @ev_src_ze: bit in event source register that
> indicates
> + * an event in Z direction
> + * @ev_ths: event threshold register address
> + * @ev_ths_mask: mask for the threshold value
> + * @ev_count:event count (period) register address
> + *
> + * Since not all chips supported by the driver support comparing high pass
> + * filtered data for events (interrupts), different interrupt sources are
> + * used for different chips and the relevant registers are included here.
> + */
> +struct mma_chip_info {
> + u8 chip_id;
> + const struct iio_chan_spec *channels;
> + int num_channels;
> + const int mma_scales[3][2];
> + u8 ev_cfg;
> + u8 ev_cfg_ele;
> + u8 ev_cfg_chan_shift;
> + u8 ev_src;
> + u8 ev_src_xe;
> + u8 ev_src_ye;
> + u8 ev_src_ze;
> + u8 ev_ths;
> + u8 ev_ths_mask;
> + u8 ev_count;
> };
>
> static int mma8452_drdy(struct mma8452_data *data)
> @@ -143,16 +190,6 @@ static const int mma8452_samp_freq[8][2] = {
> {6, 25}, {1, 56}
> };
>
> -/*
> - * Hardware has fullscale of -2G, -4G, -8G corresponding to raw value -2048
> - * The userspace interface uses m/s^2 and we declare micro units
> - * So scale factor is given by:
> - * g * N * 100 / 2048 for N = 2, 4, 8 and g = 9.80665
> - */
> -static const int mma8452_scales[3][2] = {
> - {0, 9577}, {0, 19154}, {0, 38307}
> -};
> -
> /* Datasheet table 35 (step time vs sample frequency) */
> static const int mma8452_transient_time_step_us[8] = {
> 1250,
> @@ -189,8 +226,11 @@ static ssize_t mma8452_show_scale_avail(struct device
> *dev,
> struct device_attribute *attr,
> char *buf)
> {
> - return mma8452_show_int_plus_micros(buf, mma8452_scales,
> - ARRAY_SIZE(mma8452_scales));
> + struct mma8452_data *data = iio_priv(i2c_get_clientdata(
> + to_i2c_client(dev)));
> +
> + return mma8452_show_int_plus_micros(buf, data->chip_info->mma_scales,
> + ARRAY_SIZE(data->chip_info->mma_scales));
> }
>
> static ssize_t mma8452_show_hp_cutoff_avail(struct device *dev,
> @@ -221,9 +261,8 @@ static int mma8452_get_samp_freq_index(struct
> mma8452_data *data,
>
> static int mma8452_get_scale_index(struct mma8452_data *data, int val, int
> val2)
> {
> - return mma8452_get_int_plus_micros_index(mm
Re: [PATCH 2/6] iio: mma8452: add support for MMA8453Q accelerometer chip
On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds support for the 10 bit version if Freescale's accelerometers
> of this series. The datasheet is available at Freescale's website:
>
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8453Q.pdf
>
> It creates a devicetree bindings file to document the new functionality
> and removes the driver from the trivial-devices list.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Christoph Muellner
Applied.
> ---
> .../devicetree/bindings/i2c/trivial-devices.txt| 1 -
> .../devicetree/bindings/iio/accel/mma8452.txt | 22 +
> drivers/iio/accel/Kconfig | 6 ++--
> drivers/iio/accel/mma8452.c| 37
> --
> 4 files changed, 59 insertions(+), 7 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/mma8452.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index d77d412..a50e56d 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -54,7 +54,6 @@ epson,rx8581I2C-BUS INTERFACE REAL TIME
> CLOCK MODULE
> fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
> fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for
> i.MX35/51
> fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic
> Accelerometer
> -fsl,mma8452 MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer
> fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
> fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
> gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog
> with Two-Wire Interface
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> new file mode 100644
> index 000..c3bc272
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -0,0 +1,22 @@
> +Freescale MMA8452Q or MMA8453Q triaxial accelerometer
> +
> +Required properties:
> +
> + - compatible: should contain one of
> +* "fsl,mma8452"
> +* "fsl,mma8453"
> + - reg: the I2C address of the chip
> +
> +Optional properties:
> +
> + - interrupt-parent: should be the phandle for the interrupt controller
> + - interrupts: interrupt mapping for GPIO IRQ
> +
> +Example:
> +
> + mma8453fc@1d {
> + compatible = "fsl,mma8453";
> + reg = <0x1d>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <5 0>;
> + };
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index a59047d..e4075a0 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -100,13 +100,13 @@ config KXCJK1013
> be called kxcjk-1013.
>
> config MMA8452
> - tristate "Freescale MMA8452Q Accelerometer Driver"
> + tristate "Freescale MMA8452Q and similar Accelerometers Driver"
> depends on I2C
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
> help
> - Say yes here to build support for the Freescale MMA8452Q 3-axis
> - accelerometer.
> + Say yes here to build support for the following Freescale 3-axis
> + accelerometers: MMA8452Q, MMA8453Q.
>
> To compile this driver as a module, choose M here: the module
> will be called mma8452.
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index f28428fa..7b2ab17 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1,5 +1,8 @@
> /*
> - * mma8452.c - Support for Freescale MMA8452Q 3-axis 12-bit accelerometer
> + * mma8452.c - Support for following Freescale 3-axis accelerometers:
> + *
> + * MMA8452Q (12 bit)
> + * MMA8453Q (10 bit)
> *
> * Copyright 2014 Peter Meerwald
> *
> @@ -26,7 +29,7 @@
>
> #define MMA8452_STATUS 0x00
> #define MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> -#define MMA8452_OUT_X0x01 /* MSB first,
> 12-bit */
> +#define MMA8452_OUT_X0x01 /* MSB first */
> #define MMA8452_OUT_Y0x03
> #define MMA8452_OUT_Z0x05
> #define MMA8452_INT_SRC 0x0c
> @@ -69,6 +72,7 @@
> #define MMA8452_INT_TRANS BIT(5)
>
> #define MMA8452_DEVICE_ID 0x2a
> +#define MMA8453_DEVICE_ID 0x3a
>
> struct mma8452_data {
> struct i2c_client *client;
> @@ -768,8 +772,16 @@ static const struct iio_chan_spec mma8452_channels[] = {
> IIO_CHAN_SOFT_TIMESTAMP(3),
> };
>
> +static const struct iio_chan_spec mma8453_channels[] = {
> + MMA8452_CHANNEL(X, 0, 10),
> + MMA8
Re: [PATCH 3/6] iio: mma8452: add freefall / motion interrupt source
On 01/09/15 12:45, Martin Kepplinger wrote:
> This adds the freefall / motion interrupt source definitions to the driver.
> It is used in this series' next patch, for chips that don't support the
> transient interrupt source.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Christoph Muellner
Applied.
> ---
> drivers/iio/accel/mma8452.c | 44
> 1 file changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 7b2ab17..6b1a862 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -42,6 +42,16 @@
> #define MMA8452_DATA_CFG_HPF_MASK BIT(4)
> #define MMA8452_HP_FILTER_CUTOFF 0x0f
> #define MMA8452_HP_FILTER_CUTOFF_SEL_MASK GENMASK(1, 0)
> +#define MMA8452_FF_MT_CFG0x15
> +#define MMA8452_FF_MT_CFG_OAE BIT(6)
> +#define MMA8452_FF_MT_CFG_ELE BIT(7)
> +#define MMA8452_FF_MT_SRC0x16
> +#define MMA8452_FF_MT_SRC_XHE BIT(1)
> +#define MMA8452_FF_MT_SRC_YHE BIT(3)
> +#define MMA8452_FF_MT_SRC_ZHE BIT(5)
> +#define MMA8452_FF_MT_THS0x17
> +#define MMA8452_FF_MT_THS_MASK 0x7f
> +#define MMA8452_FF_MT_COUNT 0x18
> #define MMA8452_TRANSIENT_CFG0x1d
> #define MMA8452_TRANSIENT_CFG_HPF_BYP BIT(0)
> #define MMA8452_TRANSIENT_CFG_CHAN(chan)BIT(chan + 1)
> @@ -69,6 +79,7 @@
> #define MMA8452_MAX_REG 0x31
>
> #define MMA8452_INT_DRDYBIT(0)
> +#define MMA8452_INT_FF_MT BIT(2)
> #define MMA8452_INT_TRANS BIT(5)
>
> #define MMA8452_DEVICE_ID 0x2a
> @@ -613,7 +624,8 @@ static int mma8452_write_event_config(struct iio_dev
> *indio_dev,
> else
> val &= ~BIT(chan->scan_index + chip->ev_cfg_chan_shift);
>
> - val |= MMA8452_TRANSIENT_CFG_ELE;
> + val |= chip->ev_cfg_ele;
> + val |= MMA8452_FF_MT_CFG_OAE;
>
> return mma8452_change_config(data, chip->ev_cfg, val);
> }
> @@ -654,6 +666,7 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
> {
> struct iio_dev *indio_dev = p;
> struct mma8452_data *data = iio_priv(indio_dev);
> + const struct mma_chip_info *chip = data->chip_info;
> int ret = IRQ_NONE;
> int src;
>
> @@ -666,7 +679,10 @@ static irqreturn_t mma8452_interrupt(int irq, void *p)
> ret = IRQ_HANDLED;
> }
>
> - if (src & MMA8452_INT_TRANS) {
> + if ((src & MMA8452_INT_TRANS &&
> + chip->ev_src == MMA8452_TRANSIENT_SRC) ||
> + (src & MMA8452_INT_FF_MT &&
> + chip->ev_src == MMA8452_FF_MT_SRC)) {
> mma8452_transient_interrupt(indio_dev);
> ret = IRQ_HANDLED;
> }
> @@ -728,6 +744,16 @@ static const struct iio_event_spec
> mma8452_transient_event[] = {
> },
> };
>
> +static const struct iio_event_spec mma8452_motion_event[] = {
> + {
> + .type = IIO_EV_TYPE_MAG,
> + .dir = IIO_EV_DIR_RISING,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> + .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_PERIOD)
> + },
> +};
> +
> /*
> * Threshold is configured in fixed 8G/127 steps regardless of
> * currently selected scale for measurement.
> @@ -1013,13 +1039,15 @@ static int mma8452_probe(struct i2c_client *client,
>
> if (client->irq) {
> /*
> - * Although we enable the transient interrupt source once and
> - * for all here the transient event detection itself is not
> - * enabled until userspace asks for it by
> - * mma8452_write_event_config()
> + * Although we enable the interrupt sources once and for
> + * all here the event detection itself is not enabled until
> + * userspace asks for it by mma8452_write_event_config()
>*/
> - int supported_interrupts = MMA8452_INT_DRDY | MMA8452_INT_TRANS;
> - int enabled_interrupts = MMA8452_INT_TRANS;
> + int supported_interrupts = MMA8452_INT_DRDY |
> +MMA8452_INT_TRANS |
> +MMA8452_INT_FF_MT;
> + int enabled_interrupts = MMA8452_INT_TRANS |
> + MMA8452_INT_FF_MT;
>
> /* Assume wired to INT1 pin */
> ret = i2c_smbus_write_byte_data(client,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
Re: [PATCH 5/6] iio: mma8452: add copyright notice comment
On 01/09/15 12:45, Martin Kepplinger wrote: > Signed-off-by: Martin Kepplinger > Signed-off-by: Christoph Muellner Applied. > --- > drivers/iio/accel/mma8452.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c > index 59b4455..15d50c9 100644 > --- a/drivers/iio/accel/mma8452.c > +++ b/drivers/iio/accel/mma8452.c > @@ -6,6 +6,7 @@ > * MMA8652FC (12 bit) > * MMA8653FC (10 bit) > * > + * Copyright 2015 Martin Kepplinger > * Copyright 2014 Peter Meerwald > * > * This file is subject to the terms and conditions of version 2 of > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] iio: mma8452: leave sysfs namings to the iio core
On 01/09/15 12:45, Martin Kepplinger wrote:
> This doesn't actually change anything since the core names the sysfs folder
> for the iio event attributes "events" anyways. It only leaves the job to the
> core.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Christoph Muellner
Applied to the togreg branch of iio.git - initially pushed out as testing for
the
autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/accel/mma8452.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 15d50c9..1eccc2d 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -772,7 +772,6 @@ static struct attribute *mma8452_event_attributes[] = {
>
> static struct attribute_group mma8452_event_attribute_group = {
> .attrs = mma8452_event_attributes,
> - .name = "events",
> };
>
> #define MMA8452_CHANNEL(axis, idx, bits) { \
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] iio: mma8452: add support for MMA8652FC and MMA8653FC
On 01/09/15 12:45, Martin Kepplinger wrote:
> MMA8652FC and MMA8653FC don't provide the transient interrupt source, so
> the motion interrupt source is used by providing a new iio_chan_spec
> definition, so that other supported devices are not affected by this.
>
> Datasheets for the newly supported devices are available at Freescale's
> website:
>
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8652FC.pdf
> http://cache.freescale.com/files/sensors/doc/data_sheet/MMA8653FC.pdf
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Christoph Muellner
Applied.
> ---
> .../devicetree/bindings/iio/accel/mma8452.txt | 4 +-
> drivers/iio/accel/Kconfig | 2 +-
> drivers/iio/accel/mma8452.c| 98
> --
> 3 files changed, 95 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> index c3bc272..e3c3746 100644
> --- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
> @@ -1,10 +1,12 @@
> -Freescale MMA8452Q or MMA8453Q triaxial accelerometer
> +Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
>
> Required properties:
>
>- compatible: should contain one of
> * "fsl,mma8452"
> * "fsl,mma8453"
> +* "fsl,mma8652"
> +* "fsl,mma8653"
>- reg: the I2C address of the chip
>
> Optional properties:
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index e4075a0..a37155d 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -106,7 +106,7 @@ config MMA8452
> select IIO_TRIGGERED_BUFFER
> help
> Say yes here to build support for the following Freescale 3-axis
> - accelerometers: MMA8452Q, MMA8453Q.
> + accelerometers: MMA8452Q, MMA8453Q, MMA8652FC, MMA8653FC.
>
> To compile this driver as a module, choose M here: the module
> will be called mma8452.
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 6b1a862..59b4455 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -3,6 +3,8 @@
> *
> * MMA8452Q (12 bit)
> * MMA8453Q (10 bit)
> + * MMA8652FC (12 bit)
> + * MMA8653FC (10 bit)
> *
> * Copyright 2014 Peter Meerwald
> *
> @@ -84,6 +86,8 @@
>
> #define MMA8452_DEVICE_ID 0x2a
> #define MMA8453_DEVICE_ID 0x3a
> +#define MMA8652_DEVICE_ID0x4a
> +#define MMA8653_DEVICE_ID0x5a
>
> struct mma8452_data {
> struct i2c_client *client;
> @@ -791,6 +795,26 @@ static struct attribute_group
> mma8452_event_attribute_group = {
> .num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
> }
>
> +#define MMA8652_CHANNEL(axis, idx, bits) { \
> + .type = IIO_ACCEL, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_CALIBBIAS), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .scan_index = idx, \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = (bits), \
> + .storagebits = 16, \
> + .shift = 16 - (bits), \
> + .endianness = IIO_BE, \
> + }, \
> + .event_spec = mma8452_motion_event, \
> + .num_event_specs = ARRAY_SIZE(mma8452_motion_event), \
> +}
> +
> static const struct iio_chan_spec mma8452_channels[] = {
> MMA8452_CHANNEL(X, 0, 12),
> MMA8452_CHANNEL(Y, 1, 12),
> @@ -805,9 +829,25 @@ static const struct iio_chan_spec mma8453_channels[] = {
> IIO_CHAN_SOFT_TIMESTAMP(3),
> };
>
> +static const struct iio_chan_spec mma8652_channels[] = {
> + MMA8652_CHANNEL(X, 0, 12),
> + MMA8652_CHANNEL(Y, 1, 12),
> + MMA8652_CHANNEL(Z, 2, 12),
> + IIO_CHAN_SOFT_TIMESTAMP(3),
> +};
> +
> +static const struct iio_chan_spec mma8653_channels[] = {
> + MMA8652_CHANNEL(X, 0, 10),
> + MMA8652_CHANNEL(Y, 1, 10),
> + MMA8652_CHANNEL(Z, 2, 10),
> + IIO_CHAN_SOFT_TIMESTAMP(3),
> +};
> +
> enum {
> mma8452,
> mma8453,
> + mma8652,
> + mma8653,
> };
>
> static const struct mma_chip_info mma_chip_info_table[] = {
> @@ -850,6 +890,38 @@ static const struct mma_chip_info mma_chip_info_table[]
> = {
> .ev_ths_mask = MMA8452_TRANSIENT_THS_MASK,
> .ev_count = MMA8452_TRANSIENT_COUNT,
> },
> + [mma8652] = {
> + .chip_id = MMA8652_DEVICE_ID,
> + .channels = mma8652_channels,
> + .num_channels = ARRAY_SIZE(mma8652_channels),
> + .mma_scales = { {0, 9577}, {0, 19154}, {0, 38307} },
> + .ev_cfg = MMA8452_FF_MT_CFG,
> + .ev_cfg_ele = MMA8452_FF_
[PATCH] iwlwifi: mvm: fix tof.h header guard
Commit ce7929186a39 ("iwlwifi: mvm: add basic Time of Flight (802.11mc
FTM) support") created drivers/net/wireless/iwlwifi/mvm/tof.h with a
broken header guard:
#ifndef __tof
#define __tof_h__
...
#endif /* __tof_h__ */
Use __tof_h__ in the first line.
Signed-off-by: Nicolas Iooss
---
drivers/net/wireless/iwlwifi/mvm/tof.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/tof.h
b/drivers/net/wireless/iwlwifi/mvm/tof.h
index 50ae8adaaa6e..9beebc33cb8d 100644
--- a/drivers/net/wireless/iwlwifi/mvm/tof.h
+++ b/drivers/net/wireless/iwlwifi/mvm/tof.h
@@ -60,7 +60,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/
-#ifndef __tof
+#ifndef __tof_h__
#define __tof_h__
#include "fw-api-tof.h"
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] Staging: iio: meter: Prefer using the BIT macro
On 10/09/15 17:30, Shraddha Barke wrote: > This patch replaces bit shifting on 1 with the BIT(x) macro > > This was done with coccinelle: > @@ int g; @@ > > -(1 << g) > +BIT(g) > > Signed-off-by: Shraddha Barke There are a number of places in these drivers where the use of GENMASK and a related shift macro would also improve the code, but the changes here seem sensible. I'll pick this one up. Applied to the togreg branch of iio.git. Thanks, Jonathan > --- > drivers/staging/iio/meter/ade7753.c | 8 > drivers/staging/iio/meter/ade7754.c | 6 +++--- > drivers/staging/iio/meter/ade7758_core.c | 6 +++--- > drivers/staging/iio/meter/ade7759.c | 8 > drivers/staging/iio/meter/ade7854.c | 6 +++--- > 5 files changed, 17 insertions(+), 17 deletions(-) > > diff --git a/drivers/staging/iio/meter/ade7753.c > b/drivers/staging/iio/meter/ade7753.c > index ffc7f0d..3d2e50c 100644 > --- a/drivers/staging/iio/meter/ade7753.c > +++ b/drivers/staging/iio/meter/ade7753.c > @@ -219,7 +219,7 @@ static int ade7753_reset(struct device *dev) > u16 val; > > ade7753_spi_read_reg_16(dev, ADE7753_MODE, &val); > - val |= 1 << 6; /* Software Chip Reset */ > + val |= BIT(6); /* Software Chip Reset */ > > return ade7753_spi_write_reg_16(dev, ADE7753_MODE, val); > } > @@ -328,10 +328,10 @@ static int ade7753_set_irq(struct device *dev, bool > enable) > goto error_ret; > > if (enable) > - irqen |= 1 << 3; /* Enables an interrupt when a data is > + irqen |= BIT(3); /* Enables an interrupt when a data is > present in the waveform register */ > else > - irqen &= ~(1 << 3); > + irqen &= ~BIT(3); > > ret = ade7753_spi_write_reg_8(dev, ADE7753_IRQEN, irqen); > > @@ -345,7 +345,7 @@ static int ade7753_stop_device(struct device *dev) > u16 val; > > ade7753_spi_read_reg_16(dev, ADE7753_MODE, &val); > - val |= 1 << 4; /* AD converters can be turned off */ > + val |= BIT(4); /* AD converters can be turned off */ > > return ade7753_spi_write_reg_16(dev, ADE7753_MODE, val); > } > diff --git a/drivers/staging/iio/meter/ade7754.c > b/drivers/staging/iio/meter/ade7754.c > index f12b2e5..8552c76 100644 > --- a/drivers/staging/iio/meter/ade7754.c > +++ b/drivers/staging/iio/meter/ade7754.c > @@ -223,7 +223,7 @@ static int ade7754_reset(struct device *dev) > if (ret < 0) > return ret; > > - val |= 1 << 6; /* Software Chip Reset */ > + val |= BIT(6); /* Software Chip Reset */ > return ade7754_spi_write_reg_8(dev, ADE7754_OPMODE, val); > } > > @@ -350,10 +350,10 @@ static int ade7754_set_irq(struct device *dev, bool > enable) > goto error_ret; > > if (enable) > - irqen |= 1 << 14; /* Enables an interrupt when a data is > + irqen |= BIT(14); /* Enables an interrupt when a data is >present in the waveform register */ > else > - irqen &= ~(1 << 14); > + irqen &= ~BIT(14); > > ret = ade7754_spi_write_reg_16(dev, ADE7754_IRQEN, irqen); > if (ret) > diff --git a/drivers/staging/iio/meter/ade7758_core.c > b/drivers/staging/iio/meter/ade7758_core.c > index 77141ae..3883808 100644 > --- a/drivers/staging/iio/meter/ade7758_core.c > +++ b/drivers/staging/iio/meter/ade7758_core.c > @@ -308,7 +308,7 @@ static int ade7758_reset(struct device *dev) > dev_err(dev, "Failed to read opmode reg\n"); > return ret; > } > - val |= 1 << 6; /* Software Chip Reset */ > + val |= BIT(6); /* Software Chip Reset */ > ret = ade7758_spi_write_reg_8(dev, ADE7758_OPMODE, val); > if (ret < 0) > dev_err(dev, "Failed to write opmode reg\n"); > @@ -426,10 +426,10 @@ int ade7758_set_irq(struct device *dev, bool enable) > goto error_ret; > > if (enable) > - irqen |= 1 << 16; /* Enables an interrupt when a data is > + irqen |= BIT(16); /* Enables an interrupt when a data is >present in the waveform register */ > else > - irqen &= ~(1 << 16); > + irqen &= ~BIT(16); > > ret = ade7758_spi_write_reg_24(dev, ADE7758_MASK, irqen); > if (ret) > diff --git a/drivers/staging/iio/meter/ade7759.c > b/drivers/staging/iio/meter/ade7759.c > index dbceda1..23e7392 100644 > --- a/drivers/staging/iio/meter/ade7759.c > +++ b/drivers/staging/iio/meter/ade7759.c > @@ -224,7 +224,7 @@ static int ade7759_reset(struct device *dev) > if (ret < 0) > return ret; > > - val |= 1 << 6; /* Software Chip Reset */ > + val |= BIT(6); /* Software Chip Reset */ > return ade7759_spi_write_reg_16(dev, > ADE7759_MODE, > val); > @@ -288,10 +288,10 @@ static int ade7759_set_i
Re: [PATCH 5/6] MIPS: CONFIG_MIPS_MT_SMP should depend upon CPU_MIPSR2
On Wed, Aug 05, 2015 at 03:42:39PM -0700, Paul Burton wrote: > The MT ASE cannot be used with CPUs that implement older releases of the > MIPS architecture than release 2, and is replaced in release 6. Encode > these constraints in Kconfig to ensure that MT code is only built as > part of kernels targeting an appropriate revision of the architecture. > > Signed-off-by: Paul Burton > Cc: Markos Chandras > Cc: # 3.16+ > --- > > arch/mips/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index cee5f93..ef248cf 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -2114,7 +2114,7 @@ config CPU_R4K_CACHE_TLB > > config MIPS_MT_SMP > bool "MIPS MT SMP support (1 TC on each available VPE)" > - depends on SYS_SUPPORTS_MULTITHREADING > + depends on SYS_SUPPORTS_MULTITHREADING && CPU_MIPSR2 Right now this line is depends on SYS_SUPPORTS_MULTITHREADING && !CPU_MIPSR6 which I believe is correct. The MT SMP support aka VSMP had been carefully crafted to work on older ASEs that is all use of MIPS MT instructions or features was carefully protected by cpu_has_mipsmt or similar. Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [HPDD-discuss] [PATCH] nfsd: add a new EXPORT_OP_NOWCC flag to struct export_operations
On Sat, 12 Sep 2015 04:41:33 + "Dilger, Andreas" wrote: > On 2015/09/11, 4:20 AM, "HPDD-discuss on behalf of Jeff Layton" > > wrote: > > >With NFSv3 nfsd will always attempt to send along WCC data to the > >client. This generally involves saving off the in-core inode information > >prior to doing the operation on the given filehandle, and then issuing a > >vfs_getattr to it after the op. > > > >Some filesystems (particularly clustered or networked ones) have an > >expensive ->getattr inode operation. Atomicitiy is also often difficult > >or impossible to guarantee on such filesystems. For those, we're best > >off not trying to provide WCC information to the client at all, and to > >simply allow it to poll for that information as needed with a GETATTR > >RPC. > > > >This patch adds a new flags field to struct export_operations, and > >defines a new EXPORT_OP_NOWCC flag that filesystems can use to indicate > >that nfsd should not attempt to provide WCC info in NFSv3 replies. It > >also adds a blurb about the new flags field and flag to the exporting > >documentation. > > > >The server will also now skip collecting this information for NFSv2 as > >well, since that info is never used there anyway. > > > >Note that this patch does not add this flag to any filesystem > >export_operations structures. This was originally developed to allow > >reexporting nfs via nfsd. That code is not (and may never be) suitable > >for merging into mainline. > > > >Other filesystems may want to consider enabling this flag too. It's hard > >to tell however which ones have export operations to enable export via > >knfsd and which ones mostly rely on them for open-by-filehandle support, > >so I'm leaving that up to the individual maintainers to decide. I am > >cc'ing the relevant lists for those filesystems that I think may want to > >consider adding this though. > > > >Cc: hpdd-disc...@lists.01.org > >Cc: ceph-de...@vger.kernel.org > >Cc: cluster-de...@redhat.com > >Cc: fuse-de...@lists.sourceforge.net > >Cc: ocfs2-de...@oss.oracle.com > >Signed-off-by: Jeff Layton > >--- > > Documentation/filesystems/nfs/Exporting | 27 +++ > > fs/nfsd/nfs3xdr.c | 5 - > > fs/nfsd/nfsfh.c | 14 ++ > > fs/nfsd/nfsfh.h | 5 - > > include/linux/exportfs.h| 2 ++ > > 5 files changed, 51 insertions(+), 2 deletions(-) > > > >diff --git a/Documentation/filesystems/nfs/Exporting > >b/Documentation/filesystems/nfs/Exporting > >index 520a4becb75c..fa636cde3907 100644 > >--- a/Documentation/filesystems/nfs/Exporting > >+++ b/Documentation/filesystems/nfs/Exporting > >@@ -138,6 +138,11 @@ struct which has the following members: > > to find potential names, and matches inode numbers to find the > >correct > > match. > > > >+ flags > >+Some filesystems may need to be handled differently than others. The > >+export_operations struct also includes a flags field that allows the > >+filesystem to communicate such information to nfsd. See the Export > >+Operations Flags section below for more explanation. > > > > A filehandle fragment consists of an array of 1 or more 4byte words, > > together with a one byte "type". > >@@ -147,3 +152,25 @@ generated by encode_fh, in which case it will have > >been padded with > > nuls. Rather, the encode_fh routine should choose a "type" which > > indicates the decode_fh how much of the filehandle is valid, and how > > it should be interpreted. > >+ > >+Export Operations Flags > >+--- > >+In addition to the operation vector pointers, struct export_operations > >also > >+contains a "flags" field that allows the filesystem to communicate to > >nfsd > >+that it may want to do things differently when dealing with it. The > >+following flags are defined: > >+ > >+ EXPORT_OP_NOWCC > >+RFC 1813 recommends that servers always send weak cache consistency > >+(WCC) data to the client after each operation. The server should > >+atomically collect attributes about the inode, do an operation on it, > >+and then collect the attributes afterward. This allows the client to > >+skip issuing GETATTRs in some situations but means that the server > >+is calling vfs_getattr for almost all RPCs. On some filesystems > >+(particularly those that are clustered or networked) this is > >expensive > >+and atomicity is difficult to guarantee. This flag indicates to nfsd > >+that it should skip providing WCC attributes to the client in NFSv3 > >+replies when doing operations on this filesystem. Consider enabling > >+this on filesystems that have an expensive ->getattr inode operation, > >+or when atomicity between pre and post operation attribute collection > >+is impossible to guarantee. > >diff --git a/fs/nfsd/nfs3xdr.c b/fs/nfsd/nfs3xdr.c > >index 01dcd494f781..c30c8c604e2a 100644 > >--- a/fs/nfsd/nfs3xdr.c > >+++ b/fs/nfsd/n
Re: [PATCH 1/2] pinctrl: rockchip: Define GPIO banks 7 and 8
Hi Sjoerd, Am Samstag, 12. September 2015, 00:36:44 schrieb Sjoerd Simons: > Rockchip RK3288 has 9 GPIO banks (0 to 8) add definitions for the last > two. > > Signed-off-by: Sjoerd Simons > --- > > include/dt-bindings/pinctrl/rockchip.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/dt-bindings/pinctrl/rockchip.h > b/include/dt-bindings/pinctrl/rockchip.h index 743e66a..efc57cf 100644 > --- a/include/dt-bindings/pinctrl/rockchip.h > +++ b/include/dt-bindings/pinctrl/rockchip.h > @@ -24,6 +24,8 @@ > #define RK_GPIO3 3 > #define RK_GPIO4 4 > #define RK_GPIO6 6 > +#define RK_GPIO7 7 > +#define RK_GPIO8 8 > > #define RK_FUNC_GPIO 0 > #define RK_FUNC_11 I'm actually not sure about these. In retrospect the RK_GPIOx -> x defines do not provide any additional value compared to just having the actual value in the pinctrl-nodes, so we phased them out largely for the rk3288 boards. While looking through some boards, I saw that some slipped in for stuff that gets copy'n'paste treatment most of the time, but generally we're only using the real numbers on boards - and I'd like to keep it that way and phase out the RK_GPIOx constants in new boards. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86, efi: Add "efi_fake_mem_mirror" boot option
On Wed, 09 Sep, at 04:16:09PM, Ard Biesheuvel wrote: > > Hello Taku, > > To be honest, I think that the naming of this feature is poorly > chosen. The UEFI spec gets it right by using 'MORE_RELIABLE'. Since > one way to implement more reliable memory ranges is mirroring, the > implementation detail of that has leaked into the generic naming, > which is confusing. Not your fault though, just something I wanted to > highlight. Care to suggest an alternative option? efi_fake_mem_more_reliable ? Maybe we should go further than this current design and generalise things to allow an EFI_MEMORY_ATTRIBUTE value to be specified for these memory ranges that supplements the ones actually provided by the firmware? Something like, efi_fake_mem=2G@4G:0x1,2G@0x10a000:0x1 Where 0x1 is the EFI_MEMORY_MORE_RELIABLE attribute bit. That would seem incredibly useful for testing the kernel side of the EFI_PROPERTIES_TABLE changes, i.e. you wouldn't need support in the firmware and could just "mock-up" an EFI memory map with EFI_MEMORY_XP for the data regions (code regions and EFI_MEMORY_RO are a little trickier as I understand it, because they may also contain data). > So first of all, could you please update the example so that it only > shows a single more reliable region (or two but of different sizes)? > It took me a while to figure out that those 2 GB regions are not > mirrors of each other in any way, they are simply two separate regions > that are marked as more reliable than the remaining memory. > > I do wonder if this functionality belongs in the kernel, though. I see > how it could be useful, and you can keep it as a local hack, but > generally, the firmware (OVMF?) is a better way to play around with > code like this, I think? I (partially) disagree. Using real life memory maps has its advantages, since different layouts exercise the code in different ways, and I'd really like to see this used on beefy machines with multiple GB/TB or RAM. It also allows performance measurements to be taken with bare metal accuracy. Plus there's precedent in the kernel for creating fake memory/topology objects, e.g. see numa=fake. Not everyone who touches the EFI memory mirror code is going to want (or be able) to run firmware with EFI_MEMORY_MORE_RELIABLE support. Having said that, I'd love to also see EFI_MEMORY_MORE_RELIABLE support in OVMF! I think both options make sense for different reasons. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] perf tests: Add arch tests
On Tue, 08 Sep, at 11:24:16AM, Arnaldo Carvalho de Melo wrote: > Em Mon, Sep 07, 2015 at 02:58:18PM +0200, Jiri Olsa escreveu: > > > > please base this over Arnaldo's perf/core > > Yeah, that is better, sometimes, like now, the difference from > tip/perf/core to acme/perf/core can grow as big as 50, 60 patches :-) OK, will do. > BTW I applied the first patch, with Jiri's ack, its in my perf/core Thanks! -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] perf tools: Propagate error info for the tracepoint parsing
On Mon, 07 Sep, at 10:38:05AM, Jiri Olsa wrote: > Pass 'struct parse_events_error *error' to the parse-event.c > tracepoint adding path. It will be filled with error data > in following patches. > > Link: http://lkml.kernel.org/n/tip-las1hm5zf58b0twd27h98...@git.kernel.org > Signed-off-by: Jiri Olsa > --- > tools/perf/util/parse-events.c | 27 --- > tools/perf/util/parse-events.h | 3 ++- > tools/perf/util/parse-events.y | 4 ++-- > 3 files changed, 20 insertions(+), 14 deletions(-) Reviewed-by: Matt Fleming -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] perf tests: Add arch tests
On Mon, 07 Sep, at 02:23:53PM, Jiri Olsa wrote:
> On Sat, Sep 05, 2015 at 08:02:21PM +0100, Matt Fleming wrote:
>
> SNIP
>
> > diff --git a/tools/perf/tests/builtin-test.c
> > b/tools/perf/tests/builtin-test.c
> > index 8cf0601d1662..a1b2265eaf55 100644
> > --- a/tools/perf/tests/builtin-test.c
> > +++ b/tools/perf/tests/builtin-test.c
> > @@ -14,10 +14,17 @@
> > #include "parse-options.h"
> > #include "symbol.h"
> >
> > -static struct test {
> > - const char *desc;
> > - int (*func)(void);
> > -} tests[] = {
> > +#if defined(__x86_64__) || defined(__i386__)
> > +#include "arch-tests.h"
> > +#else
> > +static struct test arch_tests[] = {
> > + {
> > + .func = NULL,
> > + },
> > +};
> > +#endif
>
> this could be defined as __weak array so we dont need to have #if above
Yeah, good idea. I'll make that change.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] perf tests: Add arch tests
On Mon, 07 Sep, at 02:28:14PM, Jiri Olsa wrote:
> On Sat, Sep 05, 2015 at 08:02:21PM +0100, Matt Fleming wrote:
>
> SNIP
>
> > };
> >
> > +static struct test *tests[] = {
> > + generic_tests,
> > + arch_tests,
> > +};
> > +
> > static bool perf_test__matches(struct test *test, int curr, int argc,
> > const char *argv[])
> > {
> > int i;
> > @@ -237,7 +229,11 @@ static int run_test(struct test *test)
> > return err;
> > }
> >
> > -#define for_each_test(t)for (t = &tests[0]; t->func; t++)
> > +static unsigned int ___j; /* This is obviously not thread-safe */
> > +
> > +#define for_each_test(t) \
> > + for (___j = 0; ___j < ARRAY_SIZE(tests); ___j++)\
> > + for (t = &tests[___j][0]; t->func; t++)
>
> why not have j on stack and pas it into for_each_test
>
> for_each_test(j, t)
> ...
Right, I made a conscious decision to not do that because I didn't
want the caller to have to care about providing an iterator variable.
It also makes the diff slightly bigger.
But I don't feel that strongly about it, so I'll make this change.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] perf tests: Add arch tests
On Mon, 07 Sep, at 02:29:54PM, Jiri Olsa wrote:
> On Sat, Sep 05, 2015 at 08:02:21PM +0100, Matt Fleming wrote:
>
> SNIP
>
> >
> > +static struct test *tests[] = {
> > + generic_tests,
> > + arch_tests,
> > +};
> > +
> > static bool perf_test__matches(struct test *test, int curr, int argc,
> > const char *argv[])
> > {
> > int i;
> > @@ -237,7 +229,11 @@ static int run_test(struct test *test)
> > return err;
> > }
> >
> > -#define for_each_test(t)for (t = &tests[0]; t->func; t++)
> > +static unsigned int ___j; /* This is obviously not thread-safe */
> > +
> > +#define for_each_test(t) \
> > + for (___j = 0; ___j < ARRAY_SIZE(tests); ___j++)\
> > + for (t = &tests[___j][0]; t->func; t++)
> >
>
> could you also split the change on adding support for arch_tests
> and another actually moving affected tests?
Sure that makes sense.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] Staging: rtl8723au: Bool tests don't need comparisons
This patch removes comparisons to true/false values on bool variables.
Fixed using Coccinelle
Change in v2-
Consider cases with false
Signed-off-by: Shraddha Barke
---
drivers/staging/rtl8723au/core/rtw_ap.c | 4 ++--
drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 4 ++--
drivers/staging/rtl8723au/core/rtw_wlan_util.c | 2 +-
drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c | 6 +++---
drivers/staging/rtl8723au/hal/rtl8723au_recv.c | 2 +-
drivers/staging/rtl8723au/hal/usb_halinit.c | 2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c
b/drivers/staging/rtl8723au/core/rtw_ap.c
index 65b209a..bd1a306 100644
--- a/drivers/staging/rtl8723au/core/rtw_ap.c
+++ b/drivers/staging/rtl8723au/core/rtw_ap.c
@@ -409,7 +409,7 @@ void add_RATid23a(struct rtw_adapter *padapter, struct
sta_info *psta, u8 rssi_l
arg |= BIT(7);/* support entry 2~31 */
- if (shortGIrate == true)
+ if (shortGIrate)
arg |= BIT(5);
tx_ra_bitmap |= ((raid<<28)&0xf000);
@@ -424,7 +424,7 @@ void add_RATid23a(struct rtw_adapter *padapter, struct
sta_info *psta, u8 rssi_l
/* arg[5] = Short GI */
rtl8723a_add_rateatid(padapter, tx_ra_bitmap, arg, rssi_level);
- if (shortGIrate == true)
+ if (shortGIrate)
init_rate |= BIT(6);
/* set ra_id, init_rate */
diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
index be9a3d5..9cab19f 100644
--- a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
@@ -4092,7 +4092,7 @@ static void rtw_site_survey(struct rtw_adapter *padapter)
/* turn on dynamic functions */
rtl8723a_odm_support_ability_restore(padapter);
- if (is_client_associated_to_ap23a(padapter) == true)
+ if (is_client_associated_to_ap23a(padapter))
issue_nulldata23a(padapter, NULL, 0, 3, 500);
rtl8723a_mlme_sitesurvey(padapter, 0);
@@ -5195,7 +5195,7 @@ void linked_status_chk23a(struct rtw_adapter *padapter)
if (psta) {
bool is_p2p_enable = false;
- if (chk_ap_is_alive(padapter, psta) == false)
+ if (!chk_ap_is_alive(padapter, psta))
rx_chk = _FAIL;
if (pxmitpriv->last_tx_pkts == pxmitpriv->tx_pkts)
diff --git a/drivers/staging/rtl8723au/core/rtw_wlan_util.c
b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
index 3c1315fc..208b24d 100644
--- a/drivers/staging/rtl8723au/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
@@ -231,7 +231,7 @@ static unsigned int ratetbl2rateset(struct rtw_adapter
*padapter,
default:
rate = ratetbl_val_2wifirate(rate);
- if (is_basicrate(padapter, rate) == true)
+ if (is_basicrate(padapter, rate))
rate |= IEEE80211_BASIC_RATE_MASK;
rateset[len] = rate;
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
index cf15f80..503231c 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
@@ -5192,7 +5192,7 @@ static void btdm_NotifyFwScan(struct rtw_adapter
*padapter, u8 scanType)
{
u8 H2C_Parameter[1] = {0};
- if (scanType == true)
+ if (scanType)
H2C_Parameter[0] = 0x1;
RTPRINT(FBT, BT_TRACE, ("[BTCoex], Notify FW for wifi scan, write 0x3b
= 0x%02x\n",
@@ -9141,7 +9141,7 @@ u8 BTDM_IsWifiConnectionExist(struct rtw_adapter
*padapter)
if (BTHCI_HsConnectionEstablished(padapter))
bRet = true;
- if (check_fwstate(&padapter->mlmepriv, WIFI_ASOC_STATE) == true)
+ if (check_fwstate(&padapter->mlmepriv, WIFI_ASOC_STATE))
bRet = true;
return bRet;
@@ -9945,7 +9945,7 @@ void BTDM_CheckBTIdleChange1Ant(struct rtw_adapter
*padapter)
}
if (!pBtMgnt->ExtConfig.bBTBusy) {
RTPRINT(FBT, BT_TRACE, ("[DM][BT], BT is idle or disable\n"));
- if (check_fwstate(&padapter->mlmepriv,
WIFI_UNDER_LINKING|WIFI_SITE_MONITOR) == true)
+ if (check_fwstate(&padapter->mlmepriv, WIFI_UNDER_LINKING |
WIFI_SITE_MONITOR))
BTDM_SetAntenna(padapter, BTDM_ANT_WIFI);
}
}
diff --git a/drivers/staging/rtl8723au/hal/rtl8723au_recv.c
b/drivers/staging/rtl8723au/hal/rtl8723au_recv.c
index 0fec84b..7acd8ae 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723au_recv.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723au_recv.c
@@ -231,7
[PATCH v2 2/4] Staging: vt6656: Bool tests don't need comparisons
This patch removes comparisons to true/false values on bool variables. Fix made using Coccinelle Change in v2- Fixing logical error Signed-off-by: Shraddha Barke --- drivers/staging/vt6656/wcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6656/wcmd.c b/drivers/staging/vt6656/wcmd.c index 3cbf479..c8e69ff 100644 --- a/drivers/staging/vt6656/wcmd.c +++ b/drivers/staging/vt6656/wcmd.c @@ -177,7 +177,7 @@ int vnt_schedule_command(struct vnt_private *priv, enum vnt_cmd command) ADD_ONE_WITH_WRAP_AROUND(priv->cmd_enqueue_idx, CMD_Q_SIZE); priv->free_cmd_queue--; - if (priv->cmd_running == false) + if (!priv->cmd_running) vnt_cmd_complete(priv); return true; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] Staging: rtl8712: Bool tests don't need comparisons
This patch removes comparisons to true/false values on bool variables.
Fix made using Coccinelle
Changes in v2-
More instances covered
Signed-off-by: Shraddha Barke
---
drivers/staging/rtl8712/rtl871x_ioctl_set.c | 24 -
drivers/staging/rtl8712/rtl871x_mlme.c | 77 ++---
2 files changed, 50 insertions(+), 51 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_set.c
b/drivers/staging/rtl8712/rtl871x_ioctl_set.c
index 22262b3..fd78941 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_set.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_set.c
@@ -136,12 +136,12 @@ u8 r8712_set_802_11_bssid(struct _adapter *padapter, u8
*bssid)
}
spin_lock_irqsave(&pmlmepriv->lock, irqL);
if (check_fwstate(pmlmepriv, _FW_UNDER_SURVEY |
- _FW_UNDER_LINKING) == true) {
+ _FW_UNDER_LINKING)) {
status = check_fwstate(pmlmepriv, _FW_UNDER_LINKING);
goto _Abort_Set_BSSID;
}
if (check_fwstate(pmlmepriv,
- _FW_LINKED|WIFI_ADHOC_MASTER_STATE) == true) {
+ _FW_LINKED|WIFI_ADHOC_MASTER_STATE)) {
if (!memcmp(&pmlmepriv->cur_network.network.MacAddress, bssid,
ETH_ALEN)) {
if (!check_fwstate(pmlmepriv, WIFI_STATION_STATE))
@@ -149,7 +149,7 @@ u8 r8712_set_802_11_bssid(struct _adapter *padapter, u8
*bssid)
* WIFI_ADHOC_MASTER_STATE */
} else {
r8712_disassoc_cmd(padapter);
- if (check_fwstate(pmlmepriv, _FW_LINKED) == true)
+ if (check_fwstate(pmlmepriv, _FW_LINKED))
r8712_ind_disconnect(padapter);
r8712_free_assoc_resources(padapter);
if ((check_fwstate(pmlmepriv,
@@ -197,7 +197,7 @@ void r8712_set_802_11_ssid(struct _adapter *padapter,
*/
r8712_disassoc_cmd(padapter);
if (check_fwstate(pmlmepriv,
- _FW_LINKED) == true)
+ _FW_LINKED))
r8712_ind_disconnect(padapter);
r8712_free_assoc_resources(padapter);
if (check_fwstate(pmlmepriv,
@@ -213,18 +213,18 @@ void r8712_set_802_11_ssid(struct _adapter *padapter,
}
} else {
r8712_disassoc_cmd(padapter);
- if (check_fwstate(pmlmepriv, _FW_LINKED) == true)
+ if (check_fwstate(pmlmepriv, _FW_LINKED))
r8712_ind_disconnect(padapter);
r8712_free_assoc_resources(padapter);
if (check_fwstate(pmlmepriv,
- WIFI_ADHOC_MASTER_STATE) == true) {
+ WIFI_ADHOC_MASTER_STATE)) {
_clr_fwstate_(pmlmepriv,
WIFI_ADHOC_MASTER_STATE);
set_fwstate(pmlmepriv, WIFI_ADHOC_STATE);
}
}
}
- if (padapter->securitypriv.btkip_countermeasure == true)
+ if (padapter->securitypriv.btkip_countermeasure)
goto _Abort_Set_SSID;
if (!validate_ssid(ssid))
goto _Abort_Set_SSID;
@@ -248,13 +248,13 @@ void r8712_set_802_11_infrastructure_mode(struct _adapter
*padapter,
if (*pold_state != networktype) {
spin_lock_irqsave(&pmlmepriv->lock, irqL);
- if ((check_fwstate(pmlmepriv, _FW_LINKED) == true) ||
+ if ((check_fwstate(pmlmepriv, _FW_LINKED)) ||
(*pold_state == Ndis802_11IBSS))
r8712_disassoc_cmd(padapter);
if (check_fwstate(pmlmepriv,
- _FW_LINKED|WIFI_ADHOC_MASTER_STATE) == true)
+ _FW_LINKED | WIFI_ADHOC_MASTER_STATE))
r8712_free_assoc_resources(padapter);
- if ((check_fwstate(pmlmepriv, _FW_LINKED) == true) ||
+ if ((check_fwstate(pmlmepriv, _FW_LINKED)) ||
(*pold_state == Ndis802_11Infrastructure) ||
(*pold_state == Ndis802_11IBSS)) {
/* will clr Linked_state before this function,
@@ -291,7 +291,7 @@ u8 r8712_set_802_11_disassociate(struct _adapter *padapter)
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
spin_lock_irqsave(&pmlmepriv->lock, irqL);
- if (check_fwstate(pmlmepriv, _FW_LINKED) == true) {
+ if (check_fwstate(pmlmepriv, _FW_LINKED)) {
r8712_disassoc_cmd(padapter);
r8712_ind_disconnect(padapter);
[PATCH v2 4/4] Staging: rtl8188eu: Bool tests don't need comparisons
This patch removes comparisons to true/false values on bool variables.
Fix made using Coccinelle
Changes in v2-
Included more instances of true and false
Signed-off-by: Shraddha Barke
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 12 ++--
drivers/staging/rtl8188eu/core/rtw_ioctl_set.c | 26 +-
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 001a2f3..591ac5d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -272,7 +272,7 @@ u8 rtw_sitesurvey_cmd(struct adapter *padapter, struct
ndis_802_11_ssid *ssid,
struct cmd_priv *pcmdpriv = &padapter->cmdpriv;
struct mlme_priv*pmlmepriv = &padapter->mlmepriv;
- if (check_fwstate(pmlmepriv, _FW_LINKED) == true)
+ if (check_fwstate(pmlmepriv, _FW_LINKED))
rtw_lps_ctrl_wk_cmd(padapter, LPS_CTRL_SCAN, 1);
ph2c = kzalloc(sizeof(struct cmd_obj), GFP_ATOMIC);
@@ -903,7 +903,7 @@ static void dynamic_chk_wk_hdl(struct adapter *padapter, u8
*pbuf, int sz)
pmlmepriv = &(padapter->mlmepriv);
#ifdef CONFIG_88EU_AP_MODE
- if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true)
+ if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
expire_timeout_chk(padapter);
#endif
@@ -920,13 +920,13 @@ static void lps_ctrl_wk_hdl(struct adapter *padapter, u8
lps_ctrl_type)
u8 mstatus;
- if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) == true) ||
- (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true))
+ if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE)) ||
+ (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE)))
return;
switch (lps_ctrl_type) {
case LPS_CTRL_SCAN:
- if (check_fwstate(pmlmepriv, _FW_LINKED) == true) {
+ if (check_fwstate(pmlmepriv, _FW_LINKED)) {
/* connect */
LPS_Leave(padapter);
}
@@ -1384,7 +1384,7 @@ void rtw_setassocsta_cmdrsp_callback(struct adapter
*padapter, struct cmd_obj *
spin_lock_bh(&pmlmepriv->lock);
- if ((check_fwstate(pmlmepriv, WIFI_MP_STATE) == true) &&
(check_fwstate(pmlmepriv, _FW_UNDER_LINKING) == true))
+ if ((check_fwstate(pmlmepriv, WIFI_MP_STATE)) &&
(check_fwstate(pmlmepriv, _FW_UNDER_LINKING)))
_clr_fwstate_(pmlmepriv, _FW_UNDER_LINKING);
set_fwstate(pmlmepriv, _FW_LINKED);
diff --git a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
index 22f5b45..8ba2689 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
@@ -89,7 +89,7 @@ u8 rtw_do_join(struct adapter *padapter)
mod_timer(&pmlmepriv->assoc_timer,
jiffies + msecs_to_jiffies(MAX_JOIN_TIMEOUT));
} else {
- if (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true)
{
+ if (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE)) {
/* submit createbss_cmd to change to a
ADHOC_MASTER */
/* pmlmepriv->lock has been acquired by
caller... */
@@ -162,7 +162,7 @@ u8 rtw_set_802_11_bssid(struct adapter *padapter, u8 *bssid)
DBG_88E("Set BSSID under fw_state = 0x%08x\n", get_fwstate(pmlmepriv));
- if (check_fwstate(pmlmepriv, _FW_UNDER_SURVEY) == true)
+ if (check_fwstate(pmlmepriv, _FW_UNDER_SURVEY))
goto handle_tkip_countermeasure;
else if (check_fwstate(pmlmepriv, _FW_UNDER_LINKING))
goto release_mlme_lock;
@@ -171,7 +171,7 @@ u8 rtw_set_802_11_bssid(struct adapter *padapter, u8 *bssid)
RT_TRACE(_module_rtl871x_ioctl_set_c_, _drv_info_, ("set_bssid:
_FW_LINKED||WIFI_ADHOC_MASTER_STATE\n"));
if (!memcmp(&pmlmepriv->cur_network.network.MacAddress, bssid,
ETH_ALEN)) {
- if (check_fwstate(pmlmepriv, WIFI_STATION_STATE) ==
false)
+ if (!check_fwstate(pmlmepriv, WIFI_STATION_STATE))
goto release_mlme_lock;/* it means driver is in
WIFI_ADHOC_MASTER_STATE, we needn't create bss again. */
} else {
RT_TRACE(_module_rtl871x_ioctl_set_c_, _drv_info_,
("Set BSSID not the same bssid\n"));
@@ -180,12 +180,12 @@ u8 rtw_set_802_11_bssid(struct adapter *padapter, u8
*bssid)
rtw_disassoc_cmd(padapter, 0, true);
- if (check_fwstate(pmlmepriv, _FW_LINKED) == true)
+ if (check_fwstate(pmlmepriv, _FW_LINKED))
rtw_indicate_disconnect(padapter);
rtw_free_assoc_resources(padapter);
Re: [PATCH 3.14 00/18] 3.14.52-stable review
On Fri, Sep 11, 2015 at 03:49:18PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.52 release.
> There are 18 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Sep 13 22:46:12 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. dmesg showd:
kmemleak: 47 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
/sys/kernel/debug/kmemleak showed lots of:
unreferenced object 0xf3204fb0 (size 1024):
comm "setfont", pid 326, jiffies 4294897405 (age 2079.568s)
hex dump (first 32 bytes):
a3 00 a0 25 92 25 b1 00 a2 00 a5 00 a9 00 ae 00 ...%.%..
c6 00 dd 00 e6 00 52 01 53 01 78 01 14 20 20 20 ..R.S.x..
backtrace:
[] kmemleak_alloc+0x3c/0xa0
[] kmem_cache_alloc_trace+0x9f/0x140
[] set_inverse_trans_unicode.isra.0+0x10a/0x120
[] con_set_unimap+0x1b2/0x230
[] vt_ioctl+0x857/0x1020
[] tty_ioctl+0x233/0xa40
[] do_vfs_ioctl+0x2e2/0x540
[] SyS_ioctl+0x60/0x90
[] sysenter_after_call+0x0/0x21
[] 0x
9e326f78713a ("tty/vt: don't set font mappings on vc not supporting this")
solved the error for me. 9e326f78713a is marked for stable also and it
will not apply cleanly.
cross_compiled with allmodconfig:
i386 - pass
x86_64 - pass
alphacheck - pass
arm - pass
cris - fail
m68k - pass
mips - pass
powerpc - pass
s390 - pass
sparc - pass
sparc64 - pass
tile - fail
tilegx - fail
xtensa - pass
build report at:
https://travis-ci.org/sudipm-mukherjee/parport/builds/79960443
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel
Petr Cvek writes: And it is true I have not tested the rootfs special case, where drivers are not yet initialized (and more specifically gpio and interrupt chip). Your backtrace should tell me if you fall into this category of issues ... but I digress, this has no link with pxaficp. >>> >>> Should I start new thread? (same bug can be present in the FICP too) >> Yes, this pxamci bothers me, it deserves a thread. > > Will start soon. And I think I see your problem now : (a) there is a regression from the commit 8c8fe97b2b8a, for which the fix is here: https://lkml.org/lkml/2015/9/6/112 (b) for gpio expanders, another fix is here : https://lkml.org/lkml/2015/9/12/62 The regression is on dmaengine, that's where the thread belongs I think, at least if that fixes your issue. >>> but STIER is not just an offset, but full register address: >>> >>> __REG(0x4074) >>> >>> So the definition should be changed, unless there is another patch I did not >>> received (in that case, send me full patchset again please) :-). >> Agreed, this is a bug in this patch. With this fix, is the pxaficp working >> or do >> you need a bit more time to experiment ? > > I have tried with a nasty hack (use only lower part of address, it should > equal with reg offset): > #undef __REG > -#define __REG(x) (x) > +#define __REG(x) (x & 0x) > > and it seems to work. The module inits and I am able to see IrDA traffic and > ping other machine. FIR mode (mostly impacted by DMA) is still untested as > magician unfortunately supports only SIR mode. Okay, I'll add a fix in the next iteration, thanks for finding this. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/23] dmaengine/ARM: Merge the edma drivers into one
On Friday 11 September 2015 05:56 PM, Peter Ujfalusi wrote: > Hi, > > Changes since v1: > - Convert edma platform device registration to use > platform_device_register_full > - Moved the PM callback also to the dmaengine driver - missed in v1 > - Commit message added to: > ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers > - New patch which reads the flag for the channel mapping support in one place > > Cover letter: > > with this series the edma two driver setup will be changed to have only one > driver to support eDMA3. The legacy edma interface will be removed and eDMA > can > only be used via dmaengine API from this point on. > In order to do the merge the following improvements has been done: > - One driver instance per eDMA: > - Any number of eDMA instances are supported (both legacy and DT boot) > - Not relying on global variables, arrays, etc > - Code simplification and optimizations in several places > > This change will also help us to do bigger changes in the eDMA driver since, > since now we have only one driver to work with. > > The series has been tested on: > da850-evm (OMAP-L138) > - with legacy and DT boot (both eDMA0 and eDMA1 is enabled) > - In code swapping the eDMA instances in legacy mode to make sure the second > instance is handled correctly. > > am335x-evmsk > - DT boot > > I think this series could go via the dmaengine tree. Changes are trivial under > arch/arm/ I looked at the series, it looks pretty good. Thanks for getting it done! No problem with entire series going through dmaengine. The week after next, when I am back in office, I would like to test on DM365 as well. But really no need to wait for it if the series is ready otherwise. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: pxa: add resources to pxaficp_ir
Add io memory and dma requestor lines to the irda pxa device. This is
part of the conversion of pxaficp_ir to dmaengine, and to shrink its
adherence to 'mach' includes.
Signed-off-by: Robert Jarzmik
Cc: Petr Cvek
---
arch/arm/mach-pxa/devices.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 35434662dc7c..9592667453b0 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -394,6 +394,26 @@ static struct resource pxa_ir_resources[] = {
.end= IRQ_ICP,
.flags = IORESOURCE_IRQ,
},
+ [3] = {
+ .start = 0x4080,
+ .end= 0x4080001b,
+ .flags = IORESOURCE_MEM,
+ },
+ [4] = {
+ .start = 0x4070,
+ .end= 0x40700023,
+ .flags = IORESOURCE_MEM,
+ },
+ [5] = {
+ .start = 17,
+ .end= 17,
+ .flags = IORESOURCE_DMA,
+ },
+ [6] = {
+ .start = 18,
+ .end= 18,
+ .flags = IORESOURCE_DMA,
+ },
};
struct platform_device pxa_device_ficp = {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: [...] > > > What's troublesome with the boot services? > > > > > > What can't be simulated? > > > > How do you want to access bare metal EFI boot services from dom0 if they > > were shutdown long time ago before loading dom0 image? > > I don't want to. > > I asked "What can't be simulated?" because I assumed everything > necessary/mandatory could be simulated without needinng access to any > real EFI boot services. > > As far as I can see all that's necessary is to provide a compatible > interface. Could you be more precise what do you need? Please enumerate. UEFI spec has more than 2500 pages and I do not think that we need all stuff in dom0. > > What do you need from EFI boot services in dom0? > > The ability to call ExitBootServices() and SetVirtualAddressMap() on a > _virtual_ address map for _virtual_ services provided by the hypervisor. I am confused. Why do you need that? Please remember, EFI is owned and operated by Xen hypervisor. dom0 does not have direct access to EFI. All stuff required in dom0 is provided via hypercalls. If you need an extra data form EFI in dom0 please extend currently exiting API. Do not emulate whole EFI if you need one or a few things from spec. > A console so that I can log things early on. IIUC, log from dom0. Please use machinery provided by Xen hypervisor. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] Staging: rtl8712: Bool tests don't need comparisons
On Sat, Sep 12, 2015 at 04:35:30PM +0530, Shraddha Barke wrote:
> This patch removes comparisons to true/false values on bool variables.
> Fix made using Coccinelle
>
> Changes in v2-
> More instances covered
>
> Signed-off-by: Shraddha Barke
> ---
You have not even build tested before sending.
> drivers/staging/rtl8712/rtl871x_ioctl_set.c | 24 -
> drivers/staging/rtl8712/rtl871x_mlme.c | 77
> ++---
> 2 files changed, 50 insertions(+), 51 deletions(-)
>
> @@ -1131,9 +1130,9 @@ int r8712_select_and_join_from_scan(struct mlme_priv
> *pmlmepriv)
> phead = &queue->queue;
> pmlmepriv->pscanned = phead->next;
> while (1) {
> - if (end_of_queue_search(phead, pmlmepriv->pscanned) == true) {
> - if ((pmlmepriv->assoc_by_rssi == true) &&
> - (pnetwork_max_rssi != NULL)) {
> + if (end_of_queue_search(phead, pmlmepriv->pscanned)) {
> + if ((pmlmepriv->assoc_by_rssi) &&
> + (pnetwork_max_rssi))
Coccinelle will not remove the opening brace.
And in one part of the patch one test for !=NULL was modified.
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation
Hi Arnd,
On Fri, 11 Sep 2015, Arnd Bergmann wrote:
> On Friday 11 September 2015 15:14:23 Peter Griffin wrote:
> > +- st,fdma-id : Must contain fdma controller number
>
> What for?
It is used by the driver to generate a unique firmware name.
Basically we need to know which controller instance we
are as each controller has a different firmware which needs
to be loaded.
Rob did say that having a index type property is undesirable
over here, see my reply at the bottom
http://www.spinics.net/lists/devicetree/msg92529.html.
However I can't think of any other useful properties we could add
to derive this information.
> > +Example:
> > +
> > + fdma1: fdma-app@8e4 {
>
> The name should be "dma-controller", not "fdma-app".
Ok will fix in v3
>
> > +Example:
> > +
> > + snd_uni_player2: snd-uni-player@2 {
> > + compatible = "st,snd_uni_player";
>
> Maybe change the compatible string to "st,snd-uni-player"?
Just checking the upstream driver which got merged for v4.3
and the compatible has changed to "st,sti-uni-player" so I
can update the DT doc example to use this in v3.
>
> The string you use here would not be acceptable for a binding.
Presumably it is the use of "underscores" in the compatible which
is not allowed? Is that correct?
regards,
Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
possible new false positive in checkpatch
Since my last pull from upstream (today) , I started seeing some
checkpatch warnings regarding suspect code indent I believe are false
positive. Take this code for example:
static int foo(void)
{
while (bar())
/* do nothing */;
}
When running checkpath on it, the following warning is emitted:
tal@tal:~/Dev/lfs/linux|0 $ scripts/checkpatch.pl -f ~/tmp/foo.c
WARNING: suspect code indent for conditional statements (8, 32)
#3: FILE: /home/tal/tmp/foo.c:3:
+ while (bar())
+ /* do nothing */;
total: 0 errors, 1 warnings, 5 lines checked
/home/tal/tmp/foo.c has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
tal@tal:~/Dev/lfs/linux|1 $
Using my limited perl knowledge, I believe the lines causing this are
3111-3133:
# remove inline comments
$s =~ s/$;/ /g;
$c =~ s/$;/ /g;
Introduced in commit 9f5af480f4554aac12e002b6f5c2b04895857700:
checkpatch: improve SUSPECT_CODE_INDENT test
Commenting out these lines removes the warning.
This pattern exists in many places around the kernel source.
Is this the intended behavior?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
Hi Lee,
On Fri, 11 Sep 2015, Lee Jones wrote:
> On Fri, 11 Sep 2015, Peter Griffin wrote:
> > On Fri, 11 Sep 2015, Lee Jones wrote:
> > > On Fri, 11 Sep 2015, Peter Griffin wrote:
> > > > On Fri, 11 Sep 2015, Lee Jones wrote:
> > > > > On Fri, 11 Sep 2015, Peter Griffin wrote:
> > > > >
> > > > > > These nodes are required to get the fdma driver working
> > > > > > on STiH407 based silicon.
> > > > > >
> > > > > > Signed-off-by: Peter Griffin
> > > > > > ---
> > > > > > arch/arm/boot/dts/stih407-family.dtsi | 51
> > > > > > +++
> > > > > > 1 file changed, 51 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > > b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > > index 838b812..da07474b 100644
> > > > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > > @@ -565,5 +565,56 @@
> > > > > > <&phy_port2
> > > > > > PHY_TYPE_USB3>;
> > > > > > };
> > > > > > };
> > > > > > +
> > > > > > + fdma0: fdma0-audio@8e2 {
> > > > >
> > > > > I'm not familiar with the FDMA driver, so can't comment knowledgeably,
> > > > > but the part of @ should only describe the
> > > > > type of hardware. I believe in this case it should just be
> > > > > dma@08e2. Also notice the leading zero in the address, which I
> > > > > believe mitigates possible confusion. Then you be more specific with
> > > > > the label, so something like 'fdma-audio' seems appropriate here.
> > > >
> > > > Ok, can change to that format in v3.
> > > >
> > > > >
> > > > > > + compatible = "st,stih407-fdma-mpe31";
> > > > > > + reg = <0x8e2 0x2>;
> > > > >
> > > > > I personally find padding up to 32bits helpful in the addresses.
> > > >
> > > > None of the stih407-family nodes I can see have this padding, including
> > > > the ones merged by you.
> > >
> > > Nither of these two facts mean it's correct.
> >
> > I thought it was a 'personal' thing. If it is mandated by the spec, then
> > that
> > is different.
> >
> > >
> > > I'm happy to write a patch to correct them all.
> >
> > Are you sure your actually correcting anything? Where does it say you
> > should have a leading zero?
> >
> > >
> > > Bear in mind that this isn't a hard and fast rule. Both work and are
> > > legal. I just think the padding is more consistent.
> >
> > Surely adding a patch with how the nodes are currently formatted, is more
> > consistent
> > than adding a patch with padding?
>
> I did mean consistent with the majority of DTS files, rather than just
> ours. There are examples of non-padded values and it's perfectly
> legal, but the vast majority of examples do in fact pad their
> addresses [see below]. The change is more of a nit than a blocker.
If its perdectly legal, than I'm personally against changing it.
Mainly because it makes it difficult for git and patch to apply
patches from the vendor kernel on top of the upstream kernel
without manual intervention.
I already ran into this with the recent stih407-pinctrl series
where every patch had to be manually fixed up because we changed
PIO to pio, on every pin definition.
I'm all for changing things where they are actually wrong in the
vendor kernel (such as not having the unit address on the reg property,
or the node name being wrong e.g. fdma to dma-controller etc. But this
doesn't appar to be one of those cases.
regards,
Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] net: irda: pxaficp_ir: use sched_clock() for time management
Instead of using directly the OS timer through direct register access,
use the standard sched_clock(), which will end up in OSCR reading
anyway.
This is a first step for direct access register removal and machine
specific code removal from this driver.
Signed-off-by: Robert Jarzmik
---
drivers/net/irda/pxaficp_ir.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c
index 100454662e4b..b1794998c68e 100644
--- a/drivers/net/irda/pxaficp_ir.c
+++ b/drivers/net/irda/pxaficp_ir.c
@@ -29,7 +29,6 @@
#include
#include
-#include
#include
#define FICP __REG(0x4080) /* Start of FICP area */
@@ -102,7 +101,7 @@
struct pxa_irda {
int speed;
int newspeed;
- unsigned long last_oscr;
+ unsigned long long last_clk;
unsigned char *dma_rx_buff;
unsigned char *dma_tx_buff;
@@ -292,7 +291,7 @@ static irqreturn_t pxa_irda_sir_irq(int irq, void *dev_id)
}
lsr = STLSR;
}
- si->last_oscr = readl_relaxed(OSCR);
+ si->last_clk = sched_clock();
break;
case 0x04: /* Received Data Available */
@@ -303,7 +302,7 @@ static irqreturn_t pxa_irda_sir_irq(int irq, void *dev_id)
dev->stats.rx_bytes++;
async_unwrap_char(dev, &dev->stats, &si->rx_buff, STRBR);
} while (STLSR & LSR_DR);
- si->last_oscr = readl_relaxed(OSCR);
+ si->last_clk = sched_clock();
break;
case 0x02: /* Transmit FIFO Data Request */
@@ -319,7 +318,7 @@ static irqreturn_t pxa_irda_sir_irq(int irq, void *dev_id)
/* We need to ensure that the transmitter has
finished. */
while ((STLSR & LSR_TEMT) == 0)
cpu_relax();
- si->last_oscr = readl_relaxed(OSCR);
+ si->last_clk = sched_clock();
/*
* Ok, we've finished transmitting. Now enable
@@ -373,7 +372,7 @@ static void pxa_irda_fir_dma_tx_irq(int channel, void *data)
while (ICSR1 & ICSR1_TBY)
cpu_relax();
- si->last_oscr = readl_relaxed(OSCR);
+ si->last_clk = sched_clock();
/*
* HACK: It looks like the TBY bit is dropped too soon.
@@ -473,8 +472,8 @@ static irqreturn_t pxa_irda_fir_irq(int irq, void *dev_id)
/* stop RX DMA */
DCSR(si->rxdma) &= ~DCSR_RUN;
- si->last_oscr = readl_relaxed(OSCR);
icsr0 = ICSR0;
+ si->last_clk = sched_clock();
if (icsr0 & (ICSR0_FRE | ICSR0_RAB)) {
if (icsr0 & ICSR0_FRE) {
@@ -549,7 +548,7 @@ static int pxa_irda_hard_xmit(struct sk_buff *skb, struct
net_device *dev)
skb_copy_from_linear_data(skb, si->dma_tx_buff, skb->len);
if (mtt)
- while ((unsigned)(readl_relaxed(OSCR) -
si->last_oscr)/4 < mtt)
+ while ((sched_clock() - si->last_clk) / 4 < mtt)
cpu_relax();
/* stop RX DMA, disable FICP */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Good day,
Good day, I am Raymond Du Plesis. I have emailed you earlier on without any response from you. On my first email I mentioned about my late client Mr. Daniel whose relatives I cannot get in touch with but both of you have the same last name, so it will be very easy to front you as his official next of kin. I am compelled to do this because I would not want the finance house to push my clients funds into their treasury as unclaimed inheritance. If you are interested you do let me know so that I can give you Comprehensive details on what we are to do. Sincerely, Raymond Du Plesis. Email:raymonddu.plesis2...@gmail.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 v2 2/3] net: irda: pxaficp_ir: convert to readl and writel
Convert the pxa IRDA driver to readl and writel primitives, and remove
another set of direct registers access. This leaves only the DMA
registers access, which will be dealt with dmaengine conversion.
Signed-off-by: Robert Jarzmik
---
Since v1: modified __REG macro to cope with STIER, ST* registers
---
drivers/net/irda/pxaficp_ir.c | 210 +-
1 file changed, 126 insertions(+), 84 deletions(-)
diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c
index b1794998c68e..4a2b3f71e4a8 100644
--- a/drivers/net/irda/pxaficp_ir.c
+++ b/drivers/net/irda/pxaficp_ir.c
@@ -29,15 +29,16 @@
#include
#include
+#undef __REG
+#define __REG(x) ((x) & 0x)
#include
-#define FICP __REG(0x4080) /* Start of FICP area */
-#define ICCR0 __REG(0x4080) /* ICP Control Register 0 */
-#define ICCR1 __REG(0x4084) /* ICP Control Register 1 */
-#define ICCR2 __REG(0x4088) /* ICP Control Register 2 */
-#define ICDR __REG(0x408c) /* ICP Data Register */
-#define ICSR0 __REG(0x40800014) /* ICP Status Register 0 */
-#define ICSR1 __REG(0x40800018) /* ICP Status Register 1 */
+#define ICCR0 0x /* ICP Control Register 0 */
+#define ICCR1 0x0004 /* ICP Control Register 1 */
+#define ICCR2 0x0008 /* ICP Control Register 2 */
+#define ICDR 0x000c /* ICP Data Register */
+#define ICSR0 0x0014 /* ICP Status Register 0 */
+#define ICSR1 0x0018 /* ICP Status Register 1 */
#define ICCR0_AME (1 << 7)/* Address match enable */
#define ICCR0_TIE (1 << 6)/* Transmit FIFO interrupt enable */
@@ -55,9 +56,7 @@
#define ICCR2_TRIG_16 (1 << 0) /* >= 16 bytes */
#define ICCR2_TRIG_32 (2 << 0) /* >= 32 bytes */
-#ifdef CONFIG_PXA27x
#define ICSR0_EOC (1 << 6)/* DMA End of Descriptor Chain */
-#endif
#define ICSR0_FRE (1 << 5)/* Framing error */
#define ICSR0_RFS (1 << 4)/* Receive FIFO service request */
#define ICSR0_TFS (1 << 3)/* Transnit FIFO service request */
@@ -98,11 +97,50 @@
IrSR_RCVEIR_UART_MODE | \
IrSR_XMITIR_IR_MODE)
+/* macros for registers read/write */
+#define ficp_writel(irda, val, off)\
+ do {\
+ dev_vdbg(irda->dev, \
+"%s():%d ficp_writel(0x%x, %s)\n", \
+__func__, __LINE__, (val), #off); \
+ writel_relaxed((val), (irda)->irda_base + (off)); \
+ } while (0)
+
+#define ficp_readl(irda, off) \
+ ({ \
+ unsigned int _v;\
+ _v = readl_relaxed((irda)->irda_base + (off)); \
+ dev_vdbg(irda->dev, \
+"%s():%d ficp_readl(%s): 0x%x\n", \
+__func__, __LINE__, #off, _v); \
+ _v; \
+ })
+
+#define stuart_writel(irda, val, off) \
+ do {\
+ dev_vdbg(irda->dev, \
+"%s():%d stuart_writel(0x%x, %s)\n", \
+__func__, __LINE__, (val), #off); \
+ writel_relaxed((val), (irda)->stuart_base + (off)); \
+ } while (0)
+
+#define stuart_readl(irda, off)
\
+ ({ \
+ unsigned int _v;\
+ _v = readl_relaxed((irda)->stuart_base + (off));\
+ dev_vdbg(irda->dev, \
+"%s():%d stuart_readl(%s): 0x%x\n",\
+__func__, __LINE__, #off, _v); \
+ _v; \
+ })
+
struct pxa_irda {
int speed;
int newspeed;
unsigned long long last_clk;
+ void __iomem*stuart_base;
+ void __iomem*irda_base;
unsigned char *dma_rx_buff;
unsigned char *dma_tx_buff;
dma_addr_t dma_rx_buff_phy;
@@ -153,7 +191,7 @@ static inline void pxa_irda_enable_sirclk(struct pxa_irda
*si)
inline st
[PATCH v2 3/3] net: irda: pxaficp_ir: dmaengine conversion
Convert pxaficp_ir to dmaengine. As pxa architecture is shifting from
raw DMA registers access to pxa_dma dmaengine driver, convert this
driver to dmaengine.
Signed-off-by: Robert Jarzmik
---
Since v1: removed mach/dma.h include, which is the goal
---
drivers/net/irda/pxaficp_ir.c | 149 +-
1 file changed, 102 insertions(+), 47 deletions(-)
diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c
index 4a2b3f71e4a8..c0b80548a43d 100644
--- a/drivers/net/irda/pxaficp_ir.c
+++ b/drivers/net/irda/pxaficp_ir.c
@@ -19,6 +19,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -27,7 +30,6 @@
#include
#include
-#include
#include
#undef __REG
#define __REG(x) ((x) & 0x)
@@ -146,8 +148,12 @@ struct pxa_irda {
dma_addr_t dma_rx_buff_phy;
dma_addr_t dma_tx_buff_phy;
unsigned intdma_tx_buff_len;
- int txdma;
- int rxdma;
+ struct dma_chan *txdma;
+ struct dma_chan *rxdma;
+ dma_cookie_trx_cookie;
+ dma_cookie_ttx_cookie;
+ int drcmr_rx;
+ int drcmr_tx;
int uart_irq;
int icp_irq;
@@ -165,6 +171,8 @@ struct pxa_irda {
struct clk *cur_clk;
};
+static int pxa_irda_set_speed(struct pxa_irda *si, int speed);
+
static inline void pxa_irda_disable_clk(struct pxa_irda *si)
{
if (si->cur_clk)
@@ -188,22 +196,41 @@ static inline void pxa_irda_enable_sirclk(struct pxa_irda
*si)
#define IS_FIR(si) ((si)->speed >= 400)
#define IRDA_FRAME_SIZE_LIMIT 2047
+static void pxa_irda_fir_dma_rx_irq(void *data);
+static void pxa_irda_fir_dma_tx_irq(void *data);
+
inline static void pxa_irda_fir_dma_rx_start(struct pxa_irda *si)
{
- DCSR(si->rxdma) = DCSR_NODESC;
- DSADR(si->rxdma) = (unsigned long)si->irda_base + ICDR;
- DTADR(si->rxdma) = si->dma_rx_buff_phy;
- DCMD(si->rxdma) = DCMD_INCTRGADDR | DCMD_FLOWSRC | DCMD_WIDTH1 |
DCMD_BURST32 | IRDA_FRAME_SIZE_LIMIT;
- DCSR(si->rxdma) |= DCSR_RUN;
+ struct dma_async_tx_descriptor *tx;
+
+ tx = dmaengine_prep_slave_single(si->rxdma, si->dma_rx_buff_phy,
+IRDA_FRAME_SIZE_LIMIT, DMA_FROM_DEVICE,
+DMA_PREP_INTERRUPT);
+ if (!tx) {
+ dev_err(si->dev, "prep_slave_sg() failed\n");
+ return;
+ }
+ tx->callback = pxa_irda_fir_dma_rx_irq;
+ tx->callback_param = si;
+ si->rx_cookie = dmaengine_submit(tx);
+ dma_async_issue_pending(si->rxdma);
}
inline static void pxa_irda_fir_dma_tx_start(struct pxa_irda *si)
{
- DCSR(si->txdma) = DCSR_NODESC;
- DSADR(si->txdma) = si->dma_tx_buff_phy;
- DTADR(si->txdma) = (unsigned long)si->irda_base + ICDR;
- DCMD(si->txdma) = DCMD_INCSRCADDR | DCMD_FLOWTRG | DCMD_ENDIRQEN |
DCMD_WIDTH1 | DCMD_BURST32 | si->dma_tx_buff_len;
- DCSR(si->txdma) |= DCSR_RUN;
+ struct dma_async_tx_descriptor *tx;
+
+ tx = dmaengine_prep_slave_single(si->txdma, si->dma_tx_buff_phy,
+si->dma_tx_buff_len, DMA_TO_DEVICE,
+DMA_PREP_INTERRUPT);
+ if (!tx) {
+ dev_err(si->dev, "prep_slave_sg() failed\n");
+ return;
+ }
+ tx->callback = pxa_irda_fir_dma_tx_irq;
+ tx->callback_param = si;
+ si->tx_cookie = dmaengine_submit(tx);
+ dma_async_issue_pending(si->rxdma);
}
/*
@@ -242,7 +269,7 @@ static int pxa_irda_set_speed(struct pxa_irda *si, int
speed)
if (IS_FIR(si)) {
/* stop RX DMA */
- DCSR(si->rxdma) &= ~DCSR_RUN;
+ dmaengine_terminate_all(si->rxdma);
/* disable FICP */
ficp_writel(si, 0, ICCR0);
pxa_irda_disable_clk(si);
@@ -388,30 +415,27 @@ static irqreturn_t pxa_irda_sir_irq(int irq, void *dev_id)
}
/* FIR Receive DMA interrupt handler */
-static void pxa_irda_fir_dma_rx_irq(int channel, void *data)
+static void pxa_irda_fir_dma_rx_irq(void *data)
{
- int dcsr = DCSR(channel);
-
- DCSR(channel) = dcsr & ~DCSR_RUN;
+ struct net_device *dev = data;
+ struct pxa_irda *si = netdev_priv(dev);
- printk(KERN_DEBUG "pxa_ir: fir rx dma bus error %#x\n", dcsr);
+ dmaengine_terminate_all(si->rxdma);
+ netdev_dbg(dev, "pxa_ir: fir rx dma bus error\n");
}
/* FIR Transmit DMA interrupt handler */
-static void pxa_irda_fir_dma_tx_irq(int channel, void *data)
+static void pxa_irda_fir_dma_tx_irq(void *data)
{
struct net_device *dev = data;
struct p
[PATCH 1/7] tty: serial: msm: Add mask value for UART_DM registers
From: Pramod Gurav
The bit masks for RFR_LEVEL1 and STALE_TIMEOUT_MSB values in MR1 and
IPR registers respectively are different for UART and UART_DM hardware
cores. We have been using UART core mask values for these. Add the same
for UART_DM core.
There is no bit setting as UART_IPR_RXSTALE_LAST for UART_DM core so do
it only for UART core.
Signed-off-by: Pramod Gurav
Reviewed-by: Stephen Boyd
Signed-off-by: Ivan T. Ivanov
---
drivers/tty/serial/msm_serial.c | 26 --
drivers/tty/serial/msm_serial.h | 2 ++
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index b73889c8ed4b..d08cfd3e1c3a 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -421,7 +421,7 @@ msm_find_best_baud(struct uart_port *port, unsigned int
baud)
static int msm_set_baud_rate(struct uart_port *port, unsigned int baud)
{
- unsigned int rxstale, watermark;
+ unsigned int rxstale, watermark, mask;
struct msm_port *msm_port = UART_TO_MSM(port);
const struct msm_baud_map *entry;
@@ -432,8 +432,15 @@ static int msm_set_baud_rate(struct uart_port *port,
unsigned int baud)
/* RX stale watermark */
rxstale = entry->rxstale;
watermark = UART_IPR_STALE_LSB & rxstale;
- watermark |= UART_IPR_RXSTALE_LAST;
- watermark |= UART_IPR_STALE_TIMEOUT_MSB & (rxstale << 2);
+ if (msm_port->is_uartdm) {
+ mask = UART_DM_IPR_STALE_TIMEOUT_MSB;
+ } else {
+ watermark |= UART_IPR_RXSTALE_LAST;
+ mask = UART_IPR_STALE_TIMEOUT_MSB;
+ }
+
+ watermark |= mask & (rxstale << 2);
+
msm_write(port, watermark, UART_IPR);
/* set RX watermark */
@@ -476,7 +483,7 @@ static void msm_init_clock(struct uart_port *port)
static int msm_startup(struct uart_port *port)
{
struct msm_port *msm_port = UART_TO_MSM(port);
- unsigned int data, rfr_level;
+ unsigned int data, rfr_level, mask;
int ret;
snprintf(msm_port->name, sizeof(msm_port->name),
@@ -496,11 +503,18 @@ static int msm_startup(struct uart_port *port)
/* set automatic RFR level */
data = msm_read(port, UART_MR1);
- data &= ~UART_MR1_AUTO_RFR_LEVEL1;
+
+ if (msm_port->is_uartdm)
+ mask = UART_DM_MR1_AUTO_RFR_LEVEL1;
+ else
+ mask = UART_MR1_AUTO_RFR_LEVEL1;
+
+ data &= ~mask;
data &= ~UART_MR1_AUTO_RFR_LEVEL0;
- data |= UART_MR1_AUTO_RFR_LEVEL1 & (rfr_level << 2);
+ data |= mask & (rfr_level << 2);
data |= UART_MR1_AUTO_RFR_LEVEL0 & rfr_level;
msm_write(port, data, UART_MR1);
+
return 0;
}
diff --git a/drivers/tty/serial/msm_serial.h b/drivers/tty/serial/msm_serial.h
index 737f69fe7113..5b7722c3938b 100644
--- a/drivers/tty/serial/msm_serial.h
+++ b/drivers/tty/serial/msm_serial.h
@@ -20,6 +20,7 @@
#define UART_MR1_AUTO_RFR_LEVEL0 0x3F
#define UART_MR1_AUTO_RFR_LEVEL1 0x3FF00
+#define UART_DM_MR1_AUTO_RFR_LEVEL10xFF00
#define UART_MR1_RX_RDY_CTL(1 << 7)
#define UART_MR1_CTS_CTL (1 << 6)
@@ -78,6 +79,7 @@
#define UART_IPR_RXSTALE_LAST 0x20
#define UART_IPR_STALE_LSB 0x1F
#define UART_IPR_STALE_TIMEOUT_MSB 0x3FF80
+#define UART_DM_IPR_STALE_TIMEOUT_MSB 0xFF80
#define UART_IPR 0x0018
#define UART_TFWR 0x001C
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] tty: serial: msm: Remove 115.2 Kbps maximum baud rate limitation
UART controller is capable to perform transfers up to 4 Mbps.
Remove artificial 115.2 Kbps limitation.
Signed-off-by: Ivan T. Ivanov
---
drivers/tty/serial/msm_serial.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 3f975392ebc0..223514979685 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -880,6 +880,7 @@ msm_find_best_baud(struct uart_port *port, unsigned int
baud)
{3, 0xdd, 8 },
{2, 0xee, 16 },
{1, 0xff, 31 },
+ {0, 0xff, 31 },
};
divisor = uart_get_divisor(port, baud);
@@ -891,16 +892,29 @@ msm_find_best_baud(struct uart_port *port, unsigned int
baud)
return entry; /* Default to smallest divider */
}
-static int msm_set_baud_rate(struct uart_port *port, unsigned int baud)
+static int msm_set_baud_rate(struct uart_port *port, unsigned int baud,
+unsigned long *saved_flags)
{
unsigned int rxstale, watermark, mask;
struct msm_port *msm_port = UART_TO_MSM(port);
const struct msm_baud_map *entry;
+ unsigned long flags;
entry = msm_find_best_baud(port, baud);
msm_write(port, entry->code, UART_CSR);
+ if (baud > 460800)
+ port->uartclk = baud * 16;
+
+ flags = *saved_flags;
+ spin_unlock_irqrestore(&port->lock, flags);
+
+ clk_set_rate(msm_port->clk, port->uartclk);
+
+ spin_lock_irqsave(&port->lock, flags);
+ *saved_flags = flags;
+
/* RX stale watermark */
rxstale = entry->rxstale;
watermark = UART_IPR_STALE_LSB & rxstale;
@@ -1024,8 +1038,8 @@ static void msm_set_termios(struct uart_port *port,
struct ktermios *termios,
msm_stop_dma(port, dma);
/* calculate and set baud rate */
- baud = uart_get_baud_rate(port, termios, old, 300, 115200);
- baud = msm_set_baud_rate(port, baud);
+ baud = uart_get_baud_rate(port, termios, old, 300, 400);
+ baud = msm_set_baud_rate(port, baud, &flags);
if (tty_termios_baud_rate(termios))
tty_termios_encode_baud_rate(termios, baud, baud);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] tty: serial: msm: Add RX DMA support
Add receive DMA support for UARTDM type of controllers.
Tested on APQ8064, which have UARTDM v1.3 and ADM DMA engine
and APQ8016, which have UARTDM v1.4 and BAM DMA engine.
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/serial/qcom,msm-uartdm.txt | 3 +
drivers/tty/serial/msm_serial.c| 230 -
drivers/tty/serial/msm_serial.h| 4 +
3 files changed, 234 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
index a600023d9ec1..182777fac9a2 100644
--- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
+++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
@@ -29,6 +29,9 @@ Optional properties:
- qcom,tx-crci: Identificator for Client Rate Control Interface to be
used with TX DMA channel. Required when using DMA for transmission
with UARTDM v1.3 and bellow.
+- qcom,rx-crci: Identificator for Client Rate Control Interface to be
+ used with RX DMA channel. Required when using DMA for reception
+ with UARTDM v1.3 and bellow.
Note: Aliases may be defined to ensure the correct ordering of the UARTs.
The alias serialN will result in the UART being assigned port N. If any
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index e40611afad09..3f975392ebc0 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,7 @@
#define UARTDM_BURST_SIZE 16 /* in bytes */
#define UARTDM_TX_AIGN(x) ((x) & ~0x3) /* valid for > 1p3 */
#define UARTDM_TX_MAX 256 /* in bytes, valid for <= 1p3 */
+#define UARTDM_RX_SIZE (UART_XMIT_SIZE / 4)
enum {
UARTDM_1P1 = 1,
@@ -73,9 +75,11 @@ struct msm_port {
unsigned intold_snap_state;
boolbreak_detected;
struct msm_dma tx_dma;
+ struct msm_dma rx_dma;
};
static void msm_handle_tx(struct uart_port *port);
+static void msm_start_rx_dma(struct msm_port *msm_port);
void msm_stop_dma(struct uart_port *port, struct msm_dma *dma)
{
@@ -114,6 +118,15 @@ static void msm_release_dma(struct msm_port *msm_port)
}
memset(dma, 0, sizeof(*dma));
+
+ dma = &msm_port->rx_dma;
+ if (dma->chan) {
+ msm_stop_dma(&msm_port->uart, dma);
+ dma_release_channel(dma->chan);
+ kfree(dma->virt);
+ }
+
+ memset(dma, 0, sizeof(*dma));
}
static void msm_request_tx_dma(struct msm_port *msm_port, resource_size_t base)
@@ -159,6 +172,54 @@ no_tx:
memset(dma, 0, sizeof(*dma));
}
+static void msm_request_rx_dma(struct msm_port *msm_port, resource_size_t base)
+{
+ struct device *dev = msm_port->uart.dev;
+ struct dma_slave_config conf;
+ struct msm_dma *dma;
+ u32 crci = 0;
+ int ret;
+
+ dma = &msm_port->rx_dma;
+
+ /* allocate DMA resources, if available */
+ dma->chan = dma_request_slave_channel_reason(dev, "rx");
+ if (IS_ERR(dma->chan))
+ goto no_rx;
+
+ of_property_read_u32(dev->of_node, "qcom,rx-crci", &crci);
+
+ dma->virt = kzalloc(UARTDM_RX_SIZE, GFP_KERNEL);
+ if (!dma->virt)
+ goto rel_rx;
+
+ memset(&conf, 0, sizeof(conf));
+ conf.direction = DMA_DEV_TO_MEM;
+ conf.device_fc = true;
+ conf.src_addr = base + UARTDM_RF;
+ conf.src_maxburst = UARTDM_BURST_SIZE;
+ conf.slave_id = crci;
+
+ ret = dmaengine_slave_config(dma->chan, &conf);
+ if (ret)
+ goto err;
+
+ dma->dir = DMA_FROM_DEVICE;
+
+ if (msm_port->is_uartdm < UARTDM_1P4)
+ dma->enable_bit = UARTDM_DMEN_RX_DM_ENABLE;
+ else
+ dma->enable_bit = UARTDM_DMEN_RX_BAM_ENABLE;
+
+ return;
+err:
+ kfree(dma->virt);
+rel_rx:
+ dma_release_channel(dma->chan);
+no_rx:
+ memset(dma, 0, sizeof(*dma));
+}
+
static inline void msm_wait_for_xmitr(struct uart_port *port)
{
while (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY)) {
@@ -306,12 +367,149 @@ unmap:
dma_unmap_single(port->dev, dma->phys, count, dma->dir);
return ret;
}
+
+static void msm_complete_rx_dma(void *args)
+{
+ struct msm_port *msm_port = args;
+ struct uart_port *port = &msm_port->uart;
+ struct tty_port *tport = &port->state->port;
+ struct msm_dma *dma = &msm_port->rx_dma;
+ int count = 0, i, sysrq;
+ unsigned long flags;
+ u32 val;
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ /* Already stopped */
+ if (!dma->count)
+ goto done;
+
+ val = msm_read(port, UARTDM_DMEN);
+ val &= ~dma->enable_bit;
+ msm_write(port, val, UAR
[PATCH 2/2] arm64: dts: qcom: 8x16: UART2 use DMA for RX and TX
Signed-off-by: Ivan T. Ivanov --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index f10ff7a2d0e3..6874221ec355 100644 --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -120,6 +120,8 @@ interrupts = ; clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>; clock-names = "core", "iface"; + dmas = <&blsp_dma 3>, <&blsp_dma 2>; + dma-names = "rx", "tx"; status = "disabled"; }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] arm64: dts: qcom: 8x16: Add UART1 configuration nodes
Add devicetree bindings for UART1 pins and device
controller with DMA channel specifiers.
Signed-off-by: Ivan T. Ivanov
---
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 29 +
arch/arm64/boot/dts/qcom/msm8916.dtsi | 12
2 files changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 568956859088..1330a7a6bcf1 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -13,6 +13,35 @@
&msmgpio {
+ blsp1_uart1_default: blsp1_uart1_default {
+ pinmux {
+ function = "blsp_uart1";
+ // TX, RX, CTS_N, RTS_N
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ };
+ pinconf {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ blsp1_uart1_sleep: blsp1_uart1_sleep {
+ pinmux {
+ function = "blsp_uart1";
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ };
+ pinconf {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
blsp1_uart2_default: blsp1_uart2_default {
pinmux {
function = "blsp_uart2";
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 5911de008dd5..f10ff7a2d0e3 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -102,6 +102,18 @@
reg = <0x180 0x8>;
};
+ blsp1_uart1: serial@78af000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0x78af000 0x200>;
+ interrupts = ;
+ clocks = <&gcc GCC_BLSP1_UART1_APPS_CLK>,
+<&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ dmas = <&blsp_dma 1>, <&blsp_dma 0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
blsp1_uart2: serial@78b {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x78b 0x200>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] tty: serial: msm: Add TX DMA support
Add transmit DMA support for UARTDM type of controllers.
Tested on APQ8064, which have UARTDM v1.3 and ADM DMA engine
and APQ8016, which have UARTDM v1.4 and BAM DMA engine.
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/serial/qcom,msm-uartdm.txt | 3 +
drivers/tty/serial/msm_serial.c| 312 +++--
drivers/tty/serial/msm_serial.h| 3 +
3 files changed, 294 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
index a2114c217376..a600023d9ec1 100644
--- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
+++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
@@ -26,6 +26,9 @@ Required properties:
Optional properties:
- dmas: Should contain dma specifiers for transmit and receive channels
- dma-names: Should contain "tx" for transmit and "rx" for receive channels
+- qcom,tx-crci: Identificator for Client Rate Control Interface to be
+ used with TX DMA channel. Required when using DMA for transmission
+ with UARTDM v1.3 and bellow.
Note: Aliases may be defined to ensure the correct ordering of the UARTs.
The alias serialN will result in the UART being assigned port N. If any
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 1c2a02634853..e40611afad09 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -20,6 +20,8 @@
#endif
#include
+#include
+#include
#include
#include
#include
@@ -39,6 +41,10 @@
#include "msm_serial.h"
+#define UARTDM_BURST_SIZE 16 /* in bytes */
+#define UARTDM_TX_AIGN(x) ((x) & ~0x3) /* valid for > 1p3 */
+#define UARTDM_TX_MAX 256 /* in bytes, valid for <= 1p3 */
+
enum {
UARTDM_1P1 = 1,
UARTDM_1P2,
@@ -46,6 +52,17 @@ enum {
UARTDM_1P4,
};
+struct msm_dma {
+ struct dma_chan *chan;
+ enum dma_data_direction dir;
+ dma_addr_t phys;
+ unsigned char *virt;
+ dma_cookie_tcookie;
+ u32 enable_bit;
+ unsigned intcount;
+ struct dma_async_tx_descriptor *desc;
+};
+
struct msm_port {
struct uart_portuart;
charname[16];
@@ -55,8 +72,93 @@ struct msm_port {
int is_uartdm;
unsigned intold_snap_state;
boolbreak_detected;
+ struct msm_dma tx_dma;
};
+static void msm_handle_tx(struct uart_port *port);
+
+void msm_stop_dma(struct uart_port *port, struct msm_dma *dma)
+{
+ struct device *dev = port->dev;
+ unsigned int mapped;
+ u32 val;
+
+ mapped = dma->count;
+ dma->count = 0;
+
+ dmaengine_terminate_all(dma->chan);
+
+ /*
+* DMA Stall happens if enqueue and flush command happens concurrently.
+* For example before changing the baud rate/protocol configuration and
+* sending flush command to ADM, disable the channel of UARTDM.
+* Note: should not reset the receiver here immediately as it is not
+* suggested to do disable/reset or reset/disable at the same time.
+*/
+ val = msm_read(port, UARTDM_DMEN);
+ val &= ~dma->enable_bit;
+ msm_write(port, val, UARTDM_DMEN);
+
+ if (mapped)
+ dma_unmap_single(dev, dma->phys, mapped, dma->dir);
+}
+
+static void msm_release_dma(struct msm_port *msm_port)
+{
+ struct msm_dma *dma;
+
+ dma = &msm_port->tx_dma;
+ if (dma->chan) {
+ msm_stop_dma(&msm_port->uart, dma);
+ dma_release_channel(dma->chan);
+ }
+
+ memset(dma, 0, sizeof(*dma));
+}
+
+static void msm_request_tx_dma(struct msm_port *msm_port, resource_size_t base)
+{
+ struct device *dev = msm_port->uart.dev;
+ struct dma_slave_config conf;
+ struct msm_dma *dma;
+ u32 crci = 0;
+ int ret;
+
+ dma = &msm_port->tx_dma;
+
+ /* allocate DMA resources, if available */
+ dma->chan = dma_request_slave_channel_reason(dev, "tx");
+ if (IS_ERR(dma->chan))
+ goto no_tx;
+
+ of_property_read_u32(dev->of_node, "qcom,tx-crci", &crci);
+
+ memset(&conf, 0, sizeof(conf));
+ conf.direction = DMA_MEM_TO_DEV;
+ conf.device_fc = true;
+ conf.dst_addr = base + UARTDM_TF;
+ conf.dst_maxburst = UARTDM_BURST_SIZE;
+ conf.slave_id = crci;
+
+ ret = dmaengine_slave_config(dma->chan, &conf);
+ if (ret)
+ goto rel_tx;
+
+ dma->dir = DMA_TO_DEVICE;
+
+ if (msm_port->is_uartdm < UARTDM_1P4)
+ dma->enable_bit = UARTDM_DMEN_TX_DM_ENABLE;
+ else
+ dma->enable_bit = UARTDM_DMEN_TX_BAM_ENABLE;
+
+ return;
+
+rel_tx:
+ dma_release_channel(dma->c
[PATCH 2/7] tty: serial: msm: replaces (1 << x) with BIT(x) macro
From: Pramod Gurav Replaces (1 << x) with BIT(x) macro Signed-off-by: Pramod Gurav Reviewed-by: Stephen Boyd Signed-off-by: Ivan T. Ivanov --- drivers/tty/serial/msm_serial.h | 44 - 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/drivers/tty/serial/msm_serial.h b/drivers/tty/serial/msm_serial.h index 5b7722c3938b..60917d30c6b5 100644 --- a/drivers/tty/serial/msm_serial.h +++ b/drivers/tty/serial/msm_serial.h @@ -21,11 +21,11 @@ #define UART_MR1_AUTO_RFR_LEVEL0 0x3F #define UART_MR1_AUTO_RFR_LEVEL1 0x3FF00 #define UART_DM_MR1_AUTO_RFR_LEVEL10xFF00 -#define UART_MR1_RX_RDY_CTL(1 << 7) -#define UART_MR1_CTS_CTL (1 << 6) +#define UART_MR1_RX_RDY_CTLBIT(7) +#define UART_MR1_CTS_CTL BIT(6) #define UART_MR2 0x0004 -#define UART_MR2_ERROR_MODE(1 << 6) +#define UART_MR2_ERROR_MODEBIT(6) #define UART_MR2_BITS_PER_CHAR 0x30 #define UART_MR2_BITS_PER_CHAR_5 (0x0 << 4) #define UART_MR2_BITS_PER_CHAR_6 (0x1 << 4) @@ -62,19 +62,19 @@ #define UART_CR_CMD_STALE_EVENT_ENABLE (80 << 4) #define UART_CR_CMD_FORCE_STALE(4 << 8) #define UART_CR_CMD_RESET_TX_READY (3 << 8) -#define UART_CR_TX_DISABLE (1 << 3) -#define UART_CR_TX_ENABLE (1 << 2) -#define UART_CR_RX_DISABLE (1 << 1) -#define UART_CR_RX_ENABLE (1 << 0) +#define UART_CR_TX_DISABLE BIT(3) +#define UART_CR_TX_ENABLE BIT(2) +#define UART_CR_RX_DISABLE BIT(1) +#define UART_CR_RX_ENABLE BIT(0) #define UART_CR_CMD_RESET_RXBREAK_START((1 << 11) | (2 << 4)) #define UART_IMR 0x0014 -#define UART_IMR_TXLEV (1 << 0) -#define UART_IMR_RXSTALE (1 << 3) -#define UART_IMR_RXLEV (1 << 4) -#define UART_IMR_DELTA_CTS (1 << 5) -#define UART_IMR_CURRENT_CTS (1 << 6) -#define UART_IMR_RXBREAK_START (1 << 10) +#define UART_IMR_TXLEV BIT(0) +#define UART_IMR_RXSTALE BIT(3) +#define UART_IMR_RXLEV BIT(4) +#define UART_IMR_DELTA_CTS BIT(5) +#define UART_IMR_CURRENT_CTS BIT(6) +#define UART_IMR_RXBREAK_START BIT(10) #define UART_IPR_RXSTALE_LAST 0x20 #define UART_IPR_STALE_LSB 0x1F @@ -98,20 +98,20 @@ #define UART_TEST_CTRL 0x0050 #define UART_SR0x0008 -#define UART_SR_HUNT_CHAR (1 << 7) -#define UART_SR_RX_BREAK (1 << 6) -#define UART_SR_PAR_FRAME_ERR (1 << 5) -#define UART_SR_OVERRUN(1 << 4) -#define UART_SR_TX_EMPTY (1 << 3) -#define UART_SR_TX_READY (1 << 2) -#define UART_SR_RX_FULL(1 << 1) -#define UART_SR_RX_READY (1 << 0) +#define UART_SR_HUNT_CHAR BIT(7) +#define UART_SR_RX_BREAK BIT(6) +#define UART_SR_PAR_FRAME_ERR BIT(5) +#define UART_SR_OVERRUNBIT(4) +#define UART_SR_TX_EMPTY BIT(3) +#define UART_SR_TX_READY BIT(2) +#define UART_SR_RX_FULLBIT(1) +#define UART_SR_RX_READY BIT(0) #define UART_RF0x000C #define UARTDM_RF 0x0070 #define UART_MISR 0x0010 #define UART_ISR 0x0014 -#define UART_ISR_TX_READY (1 << 7) +#define UART_ISR_TX_READY BIT(7) #define UARTDM_RXFS0x50 #define UARTDM_RXFS_BUF_SHIFT 0x7 -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] tty: serial: msm: Add msm prefix to all driver functions
Make function naming consistent across this driver.
No functional changes.
Signed-off-by: Ivan T. Ivanov
---
drivers/tty/serial/msm_serial.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index d08cfd3e1c3a..1c2a02634853 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -57,7 +57,7 @@ struct msm_port {
boolbreak_detected;
};
-static inline void wait_for_xmitr(struct uart_port *port)
+static inline void msm_wait_for_xmitr(struct uart_port *port)
{
while (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY)) {
if (msm_read(port, UART_ISR) & UART_ISR_TX_READY)
@@ -99,7 +99,7 @@ static void msm_enable_ms(struct uart_port *port)
msm_write(port, msm_port->imr, UART_IMR);
}
-static void handle_rx_dm(struct uart_port *port, unsigned int misr)
+static void msm_handle_rx_dm(struct uart_port *port, unsigned int misr)
{
struct tty_port *tport = &port->state->port;
unsigned int sr;
@@ -171,7 +171,7 @@ static void handle_rx_dm(struct uart_port *port, unsigned
int misr)
msm_write(port, UART_CR_CMD_STALE_EVENT_ENABLE, UART_CR);
}
-static void handle_rx(struct uart_port *port)
+static void msm_handle_rx(struct uart_port *port)
{
struct tty_port *tport = &port->state->port;
unsigned int sr;
@@ -224,14 +224,14 @@ static void handle_rx(struct uart_port *port)
spin_lock(&port->lock);
}
-static void reset_dm_count(struct uart_port *port, int count)
+static void msm_reset_dm_count(struct uart_port *port, int count)
{
- wait_for_xmitr(port);
+ msm_wait_for_xmitr(port);
msm_write(port, count, UARTDM_NCF_TX);
msm_read(port, UARTDM_NCF_TX);
}
-static void handle_tx(struct uart_port *port)
+static void msm_handle_tx(struct uart_port *port)
{
struct circ_buf *xmit = &port->state->xmit;
struct msm_port *msm_port = UART_TO_MSM(port);
@@ -250,13 +250,13 @@ static void handle_tx(struct uart_port *port)
if (port->x_char) {
if (msm_port->is_uartdm)
- reset_dm_count(port, tx_count + 1);
+ msm_reset_dm_count(port, tx_count + 1);
iowrite8_rep(tf, &port->x_char, 1);
port->icount.tx++;
port->x_char = 0;
} else if (tx_count && msm_port->is_uartdm) {
- reset_dm_count(port, tx_count);
+ msm_reset_dm_count(port, tx_count);
}
while (tf_pointer < tx_count) {
@@ -290,7 +290,7 @@ static void handle_tx(struct uart_port *port)
uart_write_wakeup(port);
}
-static void handle_delta_cts(struct uart_port *port)
+static void msm_handle_delta_cts(struct uart_port *port)
{
msm_write(port, UART_CR_CMD_RESET_CTS, UART_CR);
port->icount.cts++;
@@ -314,14 +314,14 @@ static irqreturn_t msm_irq(int irq, void *dev_id)
if (misr & (UART_IMR_RXLEV | UART_IMR_RXSTALE)) {
if (msm_port->is_uartdm)
- handle_rx_dm(port, misr);
+ msm_handle_rx_dm(port, misr);
else
- handle_rx(port);
+ msm_handle_rx(port);
}
if (misr & UART_IMR_TXLEV)
- handle_tx(port);
+ msm_handle_tx(port);
if (misr & UART_IMR_DELTA_CTS)
- handle_delta_cts(port);
+ msm_handle_delta_cts(port);
msm_write(port, msm_port->imr, UART_IMR); /* restore interrupt */
spin_unlock(&port->lock);
@@ -779,7 +779,7 @@ static void msm_poll_put_char(struct uart_port *port,
unsigned char c)
msm_write(port, 0, UART_IMR);
if (msm_port->is_uartdm)
- reset_dm_count(port, 1);
+ msm_reset_dm_count(port, 1);
/* Wait until FIFO is empty */
while (!(msm_read(port, UART_SR) & UART_SR_TX_READY))
@@ -853,7 +853,7 @@ static struct msm_port msm_uart_ports[] = {
#define UART_NRARRAY_SIZE(msm_uart_ports)
-static inline struct uart_port *get_port_from_line(unsigned int line)
+static inline struct uart_port *msm_get_port_from_line(unsigned int line)
{
return &msm_uart_ports[line].uart;
}
@@ -880,7 +880,7 @@ static void __msm_console_write(struct uart_port *port,
const char *s,
spin_lock(&port->lock);
if (is_uartdm)
- reset_dm_count(port, count);
+ msm_reset_dm_count(port, count);
i = 0;
while (i < count) {
@@ -925,7 +925,7 @@ static void msm_console_write(struct console *co, const
char *s,
BUG_ON(co->index < 0 || co->index >= UART_NR);
- port = get_port_from_line(co->index);
+ port = msm_get_port_from_line(co->index);
msm_port = UART_TO_MSM(port);
__msm_console_write(port, s, count, msm_port->is_uartdm);
@@ -942,7 +942
[PATCH 3/7] tty: serial: msm: Fix command Stale Event Enable definition
Stale Event Enable command should be 5 not 8, fix this. Signed-off-by: Ivan T. Ivanov --- drivers/tty/serial/msm_serial.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/msm_serial.h b/drivers/tty/serial/msm_serial.h index 60917d30c6b5..223f961f992a 100644 --- a/drivers/tty/serial/msm_serial.h +++ b/drivers/tty/serial/msm_serial.h @@ -59,7 +59,7 @@ #define UART_CR_CMD_SET_RFR(13 << 4) #define UART_CR_CMD_RESET_RFR (14 << 4) #define UART_CR_CMD_PROTECTION_EN (16 << 4) -#define UART_CR_CMD_STALE_EVENT_ENABLE (80 << 4) +#define UART_CR_CMD_STALE_EVENT_ENABLE (5 << 8) #define UART_CR_CMD_FORCE_STALE(4 << 8) #define UART_CR_CMD_RESET_TX_READY (3 << 8) #define UART_CR_TX_DISABLE BIT(3) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] tty: serial: msm: Add DMA support and fix bit definitions
Hi, Following patches add DMA support for UARTDM type of hardware. Changes have been tested on UARTDM v1.3(APQ8064) and v1.4(APQ8016). Patches from Gurav were published long ago here[1], I just addressed remaining comments and coding style issues. Any comments are welcome. Regards, Ivan Ivan T. Ivanov (5): tty: serial: msm: Fix command Stale Event Enable definition tty: serial: msm: Add msm prefix to all driver functions tty: serial: msm: Add TX DMA support tty: serial: msm: Add RX DMA support tty: serial: msm: Remove 115.2 Kbps maximum baud rate limitation Pramod Gurav (2): tty: serial: msm: Add mask value for UART_DM registers tty: serial: msm: replaces (1 << x) with BIT(x) macro [1] http://www.spinics.net/lists/linux-serial/msg16874.html .../devicetree/bindings/serial/qcom,msm-uartdm.txt | 6 + drivers/tty/serial/msm_serial.c| 616 +++-- drivers/tty/serial/msm_serial.h| 55 +- 3 files changed, 604 insertions(+), 73 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dmaengine: virt-dma: don't always free descriptor upon completion
Robert Jarzmik writes:
> This patch attempts to enhance the case of a transfer submitted multiple
> times, and where the cost of creating the descriptors chain is not
> negligible.
>
> This happens with big video buffers (several megabytes, ie. several
> thousands of linked descriptors in one scatter-gather list). In these
> cases, a video driver would want to do :
> - tx = dmaengine_prep_slave_sg()
> - dma_engine_submit(tx);
> - dma_async_issue_pending()
> - wait for video completion
> - read video data (or not, skipping a frame is also possible)
> - dma_engine_submit(tx)
>=> here, the descriptors chain recalculation will take time
>=> the dma coherent allocation over and over might create holes in
> the dma pool, which is counter-productive.
> - dma_async_issue_pending()
> - etc ...
>
> In order to cope with this case, virt-dma is modified to prevent freeing
> the descriptors upon completion if DMA_CTRL_REUSE flag is set in the
> transfer.
>
> This patch is a respin of the former DMA_CTRL_ACK approach, which was
> reverted due to a regression in audio drivers.
>
> Signed-off-by: Robert Jarzmik
Hi Jun, Lars-Peter and Vinod,
The revert of the former patch of this type, 8c8fe97b2b8a ("Revert "dmaengine:
virt-dma: don't always free descriptor upon completion"") broke pxa_dma driver.
The reason behind is that pxa_dma was designed, upon transfer submission (in
pxad_tx_submit()), to "move" the virtual descriptor to the submitted list,
rather than adding it at its tail (because it was previously on the allocated
list).
As a consequence, the list_head is not initialized, pxa_dma fails, and the
current status is that pxa_dma Oopses in linux-next, and therefore in Linus's
tree once the merge window is closed.
I'd really like to have this patch as the fix, ie. that at transfer preparation
in vchan_tx_prep(), the virtual descriptor is added on "allocated" list tail.
But to be sure there is no regression on other platforms, I need a test,
especially from someone who suffered from the former version of this patch
(where we had DMA_CTRL_ACK instead of DMA_CTRL_REUSE).
Could anybody give it a try, as I need a fix to go in the early -rc of v4.3
please ?
Cheers.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: similar files: fusbh200-hcd.c and fotg210-hcd.c
>> Should these files be consolidated? And if so how? > if you can find an easy way, that would be a very, very welcome patch. Is the ideal solution to consolidate both fusbh200-hcd.c and fotg210-hcd.c in a single module? If this is the case, how to detect at run time which version of the hw is present? Both are registered as platform devices and I could not find an obvious way to detect the model at run time. I could successfully load fusbh200-hcd on my fedora notebook (hp elitebook 840), and on a VM, even if neither has the hw ($ sudo modprobe fusbh200-hcd). The module loads with the warning "fusbh200_hcd should always be loaded before uhci_hcd and ohci_hcd, not after". On another workstation running ubuntu, I could load both modules at the same time, producing the same warning for each module. Should the module load if the device is not present? Other solution for consolidation would be to create a common_code.c, keeping both fusbh200-hcd.c and fotg210-hcd.c only with the code that differ. Is this better than what is there now? Other ideas? -- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: pxa: fix DFI bus lockups on startup
Robert Jarzmik writes: > After the conversion of pxa architecture to common clock framework, the > NAND clock can be disabled on startup if no nand driver claims it. > > In this case, it happens that if the bootloader used the NAND and set > the DFI arbitration bit, the next access to a static memory controller > area, such as an ethernet card, the system bus will stall, and the core > will be stalled forever. > > Fix this by clearing the DFI arbritration bit in pxa3xx startup. The bit > will be enabled the pxa3xx-nand driver on need anyway. The only left > requirement is that upon pxa3xx-nand removal, the bit should be cleared > before the clock is disabled. > > Signed-off-by: Robert Jarzmik Queued to pxa/fixes. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]
On Fri, 11 Sep 2015 17:43:15 -0400
Mike Snitzer wrote:
> Ming, Jens, others:
>
> Please see this BZ comment that speaks to a 4.3 regression due to the
> late bio splitting changes:
> https://bugzilla.redhat.com/show_bug.cgi?id=1247382#c41
I think it is a bug of bounce_end_io, and the following patch may
fix it.
>From 08df0db0be41e6bea306bcf5b4d325f5a79dc7a1 Mon Sep 17 00:00:00 2001
From: Ming Lei
Date: Sat, 12 Sep 2015 20:48:42 +0800
Subject: [PATCH] block: fix bounce_end_io
When bio bounce is involved, one new bio and its io vector are
cloned from the coming bio, which can be one fast-cloned bio
and its io vector can be shared with another bio too, especially
after bio_split() is introduced.
So it is obviously wrong to assume the start index of the original
bio's io vector is zero, which can be any value between 0 and
(bi_max_vecs - 1), especially in case of bio split.
Signed-off-by: Ming Lei
---
block/bounce.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/bounce.c b/block/bounce.c
index 0611aea..1cb5dd3 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -128,12 +128,14 @@ static void bounce_end_io(struct bio *bio, mempool_t
*pool)
struct bio *bio_orig = bio->bi_private;
struct bio_vec *bvec, *org_vec;
int i;
+ int start = bio_orig->bi_iter.bi_idx;
/*
* free up bounce indirect pages used
*/
bio_for_each_segment_all(bvec, bio, i) {
- org_vec = bio_orig->bi_io_vec + i;
+ org_vec = bio_orig->bi_io_vec + i + start;
+
if (bvec->bv_page == org_vec->bv_page)
continue;
--
1.9.1
> But inlined here so we can continue on list:
> (In reply to Josh Boyer from comment #40)
> > The function that was fixed in 4.2 doesn't exist any longer in
> > 4.3.0-0.rc0.git6.1.fc24. That kernel corresponds to Linux
> > v4.2-6105-gdd5cdb48edfd which contains commit
> > 8ae126660fddbeebb9251a174e6fa45b6ad8f932, which removed it completely. So
> > whatever fix was made in dm_merge_bvec doesn't seem to have made it to
> > whatever replaced it.
>
> The dm core fix to dm_merge_bvec was commit bd4aaf8f9b ("dm: fix
> dm_merge_bvec regression on 32 bit systems"). But I'm not sure there is
> a clear equivalent in the late bio splitting code that replaced block
> core's merge_bvec logic.
>
> merge_bvec was all about limiting bios (by asking "can/should this page
> be added to this bio?") whereas the late bio splitting is more "build
> the bios as large as possible and worry about splitting later".
IMO, given one vector can only point to one page, there shouldn't
have difference between the two.
>
> Regardless, this regression needs to be reported to Ming Lin
> , Jens Axboe and the others involved in
> maintaining the late bio splitting changes in block core.
>
> Josh and/or Adam: it would _really_ help if the regression test you guys
> are using could be handed-over and/or explained to us. Is it as simple
> as loading a 32bit with a particular config? Can you share the guest
> image if it is small enough?
Josh, Adam, would you mind testing the above patch to see if it can fix
your issue?
Thanks,
Ming
>
> Mike
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PULL] Documentation for 4.3
On Sat, 12 Sep 2015 01:59:34 -0300 Diego Viola wrote: > I really wish the commit message instead said: > > "GTK+ is an initialism" > > Can't I change the commit message any longer? No, you need to consider it set in stone at this point. jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [1/4] gpio: gpio-f7188x: Use mutex for access serialisation.
Hello Simon, On Thu, 10 Sep 2015 00:01:40 +0200, Simon Guinot wrote: > Vincent (Donnefort) finally succeeds to reproduce the issue. The setup > is quite simple. You only have to flood the gpio-f7188x driver via the > sysfs GPIO interface. Nothing more is needed. > > After some debugging we discovered that the problem comes from the > __request_region function which don't handle very well concurrent > requests on a muxed region. > > I will send a patch as a reply to this email. Please, can you test it ? I reverted my mutex-adding commit, applied given patch, and could not reproduce the error after a few minutes with my test-case, so I think this solves the issue. Tested-by: Vincent Pelletier I rebased my others gpio patches, unrelated to this issue: gpio: gpio-f7188x: Implement get_direction. gpio: gpio-f7188x: "get" should retrieve sensed level when available. gpio: gpio-f7188x: GPIO bank 0 bit 0 is not available on f71869a Should I resend ? I have not checked other model's datasheets, FWIW. Regards, -- Vincent Pelletier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
Hello, On Wed, Sep 09, 2015 at 05:49:31AM -0700, Paul Turner wrote: > I do not think this is a layering problem. This is more like C++: > there is no sane way to concurrently use all the features available, > however, reasonably self-consistent subsets may be chosen. That's just admitting failure. > > I don't get it. How is that the only consistent way? Why is making > > irreversible changes even a good way? Just layer the masks and > > trigger notification on changes. > > I'm not sure if you're agreeing or disagreeing here. Are you saying > there's another consistent way from "clobbering then triggering > notification changes" since it seems like that's what is rejected and > then described. This certainly does not include any provisions for > reversibility (which I think is a non-starter). > > With respect to layering: Are you proposing we maintain a separate > mask for sched_setaffinity and cpusets, then do different things > depending on their intersection, or lack thereof? I feel this would > introduce more consistencies than it would solve as these masks would > not be separately inspectable from user-space, leading to confusing > interactions as they are changed. So, one of the problems is that the kernel can't have tasks w/o runnable CPUs, so we have to some workaround when, for whatever reason, a task ends up with no CPU that it can run on. The other is that we never established a consistent way to deal with it in global case either. You say cpuset isn't a layering thing but that simply isn't true. It's a cgroup-scope CPU mask. It layers atop task affinities restricting what they can be configured to, limiting the effective cpumask to the intersection of actually existing CPUs and overriding individual affinity setting when the intersection doesn't exist. The kernel does not update all CPU affinity masks when a CPU goes down or comes up. It just enforces the intersection and when the intersection becomes empty, ignores it. cgroup-scoped behaviors should reflect what the system does in the global case in general, and the global behavior here, although missing some bits, is a lot saner than what cpuset is currently doing. > There are also very real challenges with how any notification is > implemented, independent of delivery: > The 'main' of an application often does not have good control or even > understanding over its own threads since many may be library managed. > Designation of responsibility for updating these masks is difficult. > That said, I think a notification would still be a useful improvement > here and that some applications would benefit. And this is the missing piece in the global case too. We've just never solved this problem properly but that does not mean we should go off and do something completely different for cgroup case. Clobbering is fine if there's a single entity controlling everything but at that level it's nothing more than a shorthand for running taskset on member tasks. > At the very least, I do not think that cpuset's behavior here can be > dismissed as unreasonable. It sure is very misguided. > > What if optimizing cache allocation across competing threads of a > > process can yield, say, 3% gain across large compute farm? Is that > > fringe? > > Frankly, yes. If you have a compute farm sufficiently dedicated to a > single application I'd say that's a fairly specialized use. I see no > reason why a more 'technical' API should be a challenge for such a > user. The fundamental point here was that it's ok for the API of some > controllers to be targeted at system rather than user control in terms > of interface. This does not restrict their use by users where > appropriate. We can go back and forth forever on this but I'm fairly sure everything CAT related is niche at this point. > So there is definitely a proliferation of discussion regarding > applying cgroups to other problems which I agree we need to take a > step back and re-examine. > > However, here we're fundamentally talking about APIs designed to > partition resources which is the problem that cgroups was introduced > to address. If we want to introduce another API to do that below the > process level we need to talk about why it's fundamentally different > for processes versus threads, and whether we want two APIs that > interface with the same underlying kernel mechanics. More on this below but going full-on cgroup controller w/ thread-level interface is akin to introducing syscalls for this. That really is what it is. > > For the cache allocation thing, I'd strongly suggest something way > > simpler and non-commmittal - e.g. create a char device node with > > simple configuration and basic access control. If this *really* turns > > out to be useful and its configuration complex enough to warrant > > cgroup integration, let's do it then, and if we actually end up there, > > I bet the interface that we'd come up with at that point would be > > different from what pe
[PATCH] drivers/staging/andrid/ashmem.c: Fix coding style issues
Signed-off-by: Martin Pietryka
---
drivers/staging/android/ashmem.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 60200a3..c549a1b 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -618,7 +618,7 @@ static int ashmem_pin(struct ashmem_area *asma, size_t
pgstart, size_t pgend)
/* Case #3: We overlap from the rear, so adjust it */
if (range->pgend <= pgend) {
- range_shrink(range, range->pgstart, pgstart-1);
+ range_shrink(range, range->pgstart, pgstart -
1);
continue;
}
@@ -715,7 +715,7 @@ static int ashmem_pin_unpin(struct ashmem_area *asma,
unsigned long cmd,
if (unlikely((pin.offset | pin.len) & ~PAGE_MASK))
return -EINVAL;
- if (unlikely(((__u32) -1) - pin.offset < pin.len))
+ if (unlikely(((__u32)-1) - pin.offset < pin.len))
return -EINVAL;
if (unlikely(PAGE_ALIGN(asma->size) < pin.offset + pin.len))
@@ -759,7 +759,7 @@ static long ashmem_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
ret = -EINVAL;
if (!asma->file) {
ret = 0;
- asma->size = (size_t) arg;
+ asma->size = (size_t)arg;
}
break;
case ASHMEM_GET_SIZE:
@@ -833,16 +833,16 @@ static int __init ashmem_init(void)
int ret;
ashmem_area_cachep = kmem_cache_create("ashmem_area_cache",
- sizeof(struct ashmem_area),
- 0, 0, NULL);
+ sizeof(struct ashmem_area),
+ 0, 0, NULL);
if (unlikely(!ashmem_area_cachep)) {
pr_err("failed to create slab cache\n");
return -ENOMEM;
}
ashmem_range_cachep = kmem_cache_create("ashmem_range_cache",
- sizeof(struct ashmem_range),
- 0, 0, NULL);
+ sizeof(struct ashmem_range),
+ 0, 0, NULL);
if (unlikely(!ashmem_range_cachep)) {
pr_err("failed to create slab cache\n");
return -ENOMEM;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: ad714x: Convert to using managed resources
Use managed resource functions devm_request_threaded_irq,
devm_inpute_allocate_device and devm_kzalloc to simplify
error handling. Also, remove use of input_unregister_device
as input_register_device itself handles it and works as
resource managed function.
To be compatible with the change, various gotos are replaced
with direct returns, and unneeded labels are dropped. With
these changes remove ad714x_remove and corresponding calls of
it as they are now redundant.
Signed-off-by: Vaishali Thakkar
---
Please note that this patch is having three lines over 80
characters as limiting them to 80 characters makes code
less readable.
---
drivers/input/misc/ad714x-i2c.c | 10 -
drivers/input/misc/ad714x-spi.c | 10 -
drivers/input/misc/ad714x.c | 88 -
drivers/input/misc/ad714x.h | 1 -
4 files changed, 26 insertions(+), 83 deletions(-)
diff --git a/drivers/input/misc/ad714x-i2c.c b/drivers/input/misc/ad714x-i2c.c
index 189bdc8..2f04773 100644
--- a/drivers/input/misc/ad714x-i2c.c
+++ b/drivers/input/misc/ad714x-i2c.c
@@ -85,15 +85,6 @@ static int ad714x_i2c_probe(struct i2c_client *client,
return 0;
}
-static int ad714x_i2c_remove(struct i2c_client *client)
-{
- struct ad714x_chip *chip = i2c_get_clientdata(client);
-
- ad714x_remove(chip);
-
- return 0;
-}
-
static const struct i2c_device_id ad714x_id[] = {
{ "ad7142_captouch", 0 },
{ "ad7143_captouch", 0 },
@@ -110,7 +101,6 @@ static struct i2c_driver ad714x_i2c_driver = {
.pm = &ad714x_i2c_pm,
},
.probe= ad714x_i2c_probe,
- .remove = ad714x_i2c_remove,
.id_table = ad714x_id,
};
diff --git a/drivers/input/misc/ad714x-spi.c b/drivers/input/misc/ad714x-spi.c
index a79e50b..c8170f0 100644
--- a/drivers/input/misc/ad714x-spi.c
+++ b/drivers/input/misc/ad714x-spi.c
@@ -101,15 +101,6 @@ static int ad714x_spi_probe(struct spi_device *spi)
return 0;
}
-static int ad714x_spi_remove(struct spi_device *spi)
-{
- struct ad714x_chip *chip = spi_get_drvdata(spi);
-
- ad714x_remove(chip);
-
- return 0;
-}
-
static struct spi_driver ad714x_spi_driver = {
.driver = {
.name = "ad714x_captouch",
@@ -117,7 +108,6 @@ static struct spi_driver ad714x_spi_driver = {
.pm = &ad714x_spi_pm,
},
.probe = ad714x_spi_probe,
- .remove = ad714x_spi_remove,
};
module_spi_driver(ad714x_spi_driver);
diff --git a/drivers/input/misc/ad714x.c b/drivers/input/misc/ad714x.c
index 7a61e9e..c94d0c0 100644
--- a/drivers/input/misc/ad714x.c
+++ b/drivers/input/misc/ad714x.c
@@ -982,25 +982,25 @@ struct ad714x_chip *ad714x_probe(struct device *dev, u16
bus_type, int irq,
if (irq <= 0) {
dev_err(dev, "IRQ not configured!\n");
error = -EINVAL;
- goto err_out;
+ return ERR_PTR(error);
}
if (dev_get_platdata(dev) == NULL) {
dev_err(dev, "platform data for ad714x doesn't exist\n");
error = -EINVAL;
- goto err_out;
+ return ERR_PTR(error);
}
- ad714x = kzalloc(sizeof(*ad714x) + sizeof(*ad714x->sw) +
-sizeof(*sd_drv) * plat_data->slider_num +
-sizeof(*wl_drv) * plat_data->wheel_num +
-sizeof(*tp_drv) * plat_data->touchpad_num +
-sizeof(*bt_drv) * plat_data->button_num, GFP_KERNEL);
+ ad714x = devm_kzalloc(dev, sizeof(*ad714x) + sizeof(*ad714x->sw) +
+ sizeof(*sd_drv) * plat_data->slider_num +
+ sizeof(*wl_drv) * plat_data->wheel_num +
+ sizeof(*tp_drv) * plat_data->touchpad_num +
+ sizeof(*bt_drv) * plat_data->button_num,
+ GFP_KERNEL);
if (!ad714x) {
error = -ENOMEM;
- goto err_out;
+ return ERR_PTR(error);
}
-
ad714x->hw = plat_data;
drv_mem = ad714x + 1;
@@ -1022,7 +1022,7 @@ struct ad714x_chip *ad714x_probe(struct device *dev, u16
bus_type, int irq,
error = ad714x_hw_detect(ad714x);
if (error)
- goto err_free_mem;
+ return ERR_PTR(error);
/* initialize and request sw/hw resources */
@@ -1039,10 +1039,10 @@ struct ad714x_chip *ad714x_probe(struct device *dev,
u16 bus_type, int irq,
struct ad714x_slider_plat *sd_plat = ad714x->hw->slider;
for (i = 0; i < ad714x->hw->slider_num; i++) {
- sd_drv[i].input = input[alloc_idx] =
input_allocate_device();
+ sd_drv[i].input = input[alloc_idx] =
devm_input_allocate_device(dev);
if (!input[alloc_idx]) {
erro
Re: [PATCH 5/6] MIPS: CONFIG_MIPS_MT_SMP should depend upon CPU_MIPSR2
On Sat, Sep 12, 2015 at 12:16:39PM +0200, Ralf Baechle wrote: > > config MIPS_MT_SMP > > bool "MIPS MT SMP support (1 TC on each available VPE)" > > - depends on SYS_SUPPORTS_MULTITHREADING > > + depends on SYS_SUPPORTS_MULTITHREADING && CPU_MIPSR2 > > Right now this line is > > depends on SYS_SUPPORTS_MULTITHREADING && !CPU_MIPSR6 > > which I believe is correct. The MT SMP support aka VSMP had been > carefully crafted to work on older ASEs that is all use of MIPS MT > instructions or features was carefully protected by cpu_has_mipsmt > or similar. I disagree. The "background" section in the introduction to the MT ASE spec (MD00376, revision 1.12) reads: > Multi-threading, or the concurrent presence of multiple active threads > or contexts of execution on the same CPU, is an increasingly > widely-used technique for tolerating memory and execution latency and > for getting higher utilization out of processor functional units. The > MIPS® Multi-threading (MT) Module is an extension to Release 2 (and > newer) of the MIPS32® Architecture which provides a framework for > multi-threading the MIPS processor architecture. MT is quite clearly an extension to r2. The MT bit in Config3 has this note in the MIPS32 PRA (MD00088, revision 6.01): > For Release 6 and MIPS after, this bit must be 0. Thus MT is an option from r2 <= ISA < r6. The current !CPU_MIPSR6 constraint in Kconfig only enforces half of that. Depending upon CPU_MIPSR2 would enforce the whole. Thanks, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] MIPS: CPS: drop .set mips64r2 directives
Thanks John,
That's fine & understood, it's the month before that when these sat
quietly - through the release of a kernel which they fix a regression in
no less, and despite my having asked Ralf on IRC about them a couple of
weeks before v4.2 was released.
If they just fell off the radar or through the cracks, fine, it happens.
I just want to be sure that regression gets fixed as soon as possible.
Thanks,
Paul
On Sat, Sep 12, 2015 at 08:13:07AM +0200, John Crispin wrote:
> Hi Paul,
>
> --> http://www.linux-mips.org/archives/linux-mips/2015-09/msg00057.html
>
> John
>
> On 10/09/2015 20:03, Paul Burton wrote:
> > Ralf: is there a reason you've only applied patch 1 of this series?
> >
> > v4.2 is broken because these didn't get in (despite being submitted well
> > before the release), and master is still broken because they still
> > haven't gotten in. If there's a reason you didn't merge them please let
> > me know, otherwise please can we get them in ASAP.
> >
> > Thanks,
> > Paul
> >
> > On Wed, Aug 05, 2015 at 03:42:40PM -0700, Paul Burton wrote:
> >> Commit 977e043d5ea1 ("MIPS: kernel: cps-vec: Replace mips32r2 ISA level
> >> with mips64r2") leads to .set mips64r2 directives being present in 32
> >> bit (ie. CONFIG_32BIT=y) kernels. This is incorrect & leads to MIPS64
> >> instructions being emitted by the assembler when expanding
> >> pseudo-instructions. For example the "move" instruction can legitimately
> >> be expanded to a "daddu". This causes problems when the kernel is run on
> >> a MIPS32 CPU, as CONFIG_32BIT kernels of course often are...
> >>
> >> Fix this by dropping the .set directives entirely now that Kconfig
> >> should be ensuring that kernels including this code are built with a
> >> suitable -march= compiler flag.
> >>
> >> Signed-off-by: Paul Burton
> >> Cc: Markos Chandras
> >> Cc: # 3.16+
> >> ---
> >>
> >> arch/mips/kernel/cps-vec.S | 2 --
> >> 1 file changed, 2 deletions(-)
> >>
> >> diff --git a/arch/mips/kernel/cps-vec.S b/arch/mips/kernel/cps-vec.S
> >> index 209ded1..763d8b7 100644
> >> --- a/arch/mips/kernel/cps-vec.S
> >> +++ b/arch/mips/kernel/cps-vec.S
> >> @@ -229,7 +229,6 @@ LEAF(mips_cps_core_init)
> >>has_mt t0, 3f
> >>
> >>.setpush
> >> - .setmips64r2
> >>.setmt
> >>
> >>/* Only allow 1 TC per VPE to execute... */
> >> @@ -348,7 +347,6 @@ LEAF(mips_cps_boot_vpes)
> >> nop
> >>
> >>.setpush
> >> - .setmips64r2
> >>.setmt
> >>
> >> 1:/* Enter VPE configuration state */
> >> --
> >> 2.5.0
> >>
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Staging: iio: cdc: Prefer using the BIT macro
On Sat, Sep 12, 2015 at 04:47:23PM +0530, Shraddha Barke wrote: > > > On Sat, Sep 12, 2015 at 3:17 PM, Jonathan Cameron wrote: > > On 10/09/15 17:32, Shraddha Barke wrote: > > This patch replaces bit shifting on 1 with the BIT(x) macro > > > > This was done with coccinelle: > > @@ int g; @@ > > > > -(1 << g) > > +BIT(g) > > > > Signed-off-by: Shraddha Barke > Something odd happened here as this is only a small proportion of the > cases > that should be updated in this file. There's one at the bottom of the > patch for starters! > > > I didn't apply BIT(x) for mixed cases.I think I should drop this patch > altogether but > Greg has added it. Will it cause problems ? :( Greg can always drop it :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Documentation: bindings: Add the Allwinner A10 codec bindings
The Allwinner SoCs have an in-SoC audio controller taking the role of a DAI
and a codec.
Add the binding documentation for that controller on the A10.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/sound/sun4i-codec.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/sun4i-codec.txt
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
new file mode 100644
index ..680144b74ae9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -0,0 +1,33 @@
+* Allwinner A10 Codec
+
+Required properties:
+- compatible: must be either "allwinner,sun4i-a10-codec" or
+ "allwinner,sun7i-a20-codec"
+- reg: must contain the registers location and length
+- interrupts: must contain the codec interrupt
+- dmas: DMA channels for tx and rx dma. See the DMA client binding,
+ Documentation/devicetree/bindings/dma/dma.txt
+- dma-names: should include "tx" and "rx".
+- clocks: a list of phandle + clock-specifer pairs, one for each entry
+ in clock-names.
+- clock-names: should contain followings:
+ - "apb": the parent APB clock for this controller
+ - "codec": the parent module clock
+- routing : A list of the connections between audio components. Each
+ entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source.
+
+
+Example:
+codec: codec@01c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun7i-a20-codec";
+ reg = <0x01c22c00 0x40>;
+ interrupts = <0 30 4>;
+ clocks = <&apb0_gates 0>, <&codec_clk>;
+ clock-names = "apb", "codec";
+ dmas = <&dma 0 19>, <&dma 0 19>;
+ dma-names = "rx", "tx";
+ routing = "Headphone Jack", "HP Right",
+ "Headphone Jack", "HP Left";
+};
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] ASoC: Add support for the Allwinner A10 codec
Hi everyone, This patch set adds the support for what Allwinner calls the codec on their SoCs. This codec is actually a combination of a codec and DAI, tied together in a single memory-mapped IP. It is completely standalone, and outputs directly the analog signal. While it supports both playback and capture, the capture is not implemented in this patch, and will be posted eventually as a separate one. This set, in order to be functional, has a dependency on the audio clocks patch set posted separately. However, it doesn't needs this to compile properly, so I guess it can be merged without really caring for the merging status of the clock patches. Let me know what you think, Maxime Emilio López (1): ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs Maxime Ripard (1): Documentation: bindings: Add the Allwinner A10 codec bindings .../devicetree/bindings/sound/sun4i-codec.txt | 33 + sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/sunxi/Kconfig| 11 + sound/soc/sunxi/Makefile | 2 + sound/soc/sunxi/sun4i-codec.c | 720 + 6 files changed, 767 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/sun4i-codec.txt create mode 100644 sound/soc/sunxi/Kconfig create mode 100644 sound/soc/sunxi/Makefile create mode 100644 sound/soc/sunxi/sun4i-codec.c -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs
From: Emilio López The sun4i, sun5i and sun7i SoC families have a built-in codec, capable of both audio capture and playback. While this is called a codec by Allwinner, it really is an in-SoC combination of a codec and a DAI, with its own DAC/ADC and amplifiers in a single memory-mapped controller. The capture part has been left out for now, and will be added eventually. Signed-off-by: Emilio López Signed-off-by: Maxime Ripard --- sound/soc/Kconfig | 1 + sound/soc/Makefile| 1 + sound/soc/sunxi/Kconfig | 11 + sound/soc/sunxi/Makefile | 2 + sound/soc/sunxi/sun4i-codec.c | 720 ++ 5 files changed, 735 insertions(+) create mode 100644 sound/soc/sunxi/Kconfig create mode 100644 sound/soc/sunxi/Makefile create mode 100644 sound/soc/sunxi/sun4i-codec.c diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index 2ae9619443d1..79c12008c4f0 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -54,6 +54,7 @@ source "sound/soc/samsung/Kconfig" source "sound/soc/sh/Kconfig" source "sound/soc/sirf/Kconfig" source "sound/soc/spear/Kconfig" +source "sound/soc/sunxi/Kconfig" source "sound/soc/tegra/Kconfig" source "sound/soc/txx9/Kconfig" source "sound/soc/ux500/Kconfig" diff --git a/sound/soc/Makefile b/sound/soc/Makefile index e189903fabf4..3bf920252435 100644 --- a/sound/soc/Makefile +++ b/sound/soc/Makefile @@ -36,6 +36,7 @@ obj-$(CONFIG_SND_SOC) += samsung/ obj-$(CONFIG_SND_SOC) += sh/ obj-$(CONFIG_SND_SOC) += sirf/ obj-$(CONFIG_SND_SOC) += spear/ +obj-$(CONFIG_SND_SOC) += sunxi/ obj-$(CONFIG_SND_SOC) += tegra/ obj-$(CONFIG_SND_SOC) += txx9/ obj-$(CONFIG_SND_SOC) += ux500/ diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig new file mode 100644 index ..84c72ec6ad73 --- /dev/null +++ b/sound/soc/sunxi/Kconfig @@ -0,0 +1,11 @@ +menu "Allwinner SoC Audio support" + +config SND_SUN4I_CODEC + tristate "Allwinner A10 Codec Support" + select SND_SOC_GENERIC_DMAENGINE_PCM + select REGMAP_MMIO + help + Select Y or M to add support for the Codec embedded in the Allwinner + A10 and affiliated SoCs. + +endmenu diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile new file mode 100644 index ..ea8a08c881d6 --- /dev/null +++ b/sound/soc/sunxi/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o + diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c new file mode 100644 index ..6e83e62ef039 --- /dev/null +++ b/sound/soc/sunxi/sun4i-codec.c @@ -0,0 +1,720 @@ +/* + * Copyright 2014 Emilio López + * Copyright 2014 Jon Smirl + * Copyright 2015 Maxime Ripard + * + * Based on the Allwinner SDK driver, released under the GPL. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* Codec DAC register offsets and bit fields */ +#define SUN4I_CODEC_DAC_DPC(0x00) +#define SUN4I_CODEC_DAC_DPC_EN_DA (31) +#define SUN4I_CODEC_DAC_DPC_DVOL (12) +#define SUN4I_CODEC_DAC_FIFOC (0x04) +#define SUN4I_CODEC_DAC_FIFOC_DAC_FS (29) +#define SUN4I_CODEC_DAC_FIFOC_FIR_VERSION (28) +#define SUN4I_CODEC_DAC_FIFOC_SEND_LASAT (26) +#define SUN4I_CODEC_DAC_FIFOC_TX_FIFO_MODE (24) +#define SUN4I_CODEC_DAC_FIFOC_DRQ_CLR_CNT (21) +#define SUN4I_CODEC_DAC_FIFOC_TX_TRIG_LEVEL(8) +#define SUN4I_CODEC_DAC_FIFOC_MONO_EN (6) +#define SUN4I_CODEC_DAC_FIFOC_TX_SAMPLE_BITS (5) +#define SUN4I_CODEC_DAC_FIFOC_DAC_DRQ_EN (4) +#define SUN4I_CODEC_DAC_FIFOC_FIFO_FLUSH (0) +#define SUN4I_CODEC_DAC_FIFOS (0x08) +#define SUN4I_CODEC_DAC_TXDATA (0x0c) +#define SUN4I_CODEC_DAC_ACTL (0x10) +#define SUN4I_CODEC_DAC_ACTL_DACAENR (31) +#define SUN4I_CODEC_DAC_ACTL_DACAENL (30) +#define SUN4I_CODEC_DAC_ACTL_MIXEN (29) +#define SUN4I_CODEC_DAC_ACTL_LDACLMIXS (15) +#define SUN4I_CODEC_DAC_ACTL_RDACRMIXS (14) +#define SUN4I_CODEC_DAC_ACTL_LDACRMIXS (13) +#define SUN4I_CODEC_DAC_ACTL_DACPAS(8)
