[PATCH] staging: pi433: Cleanup codestyle, indent statements after case labels

2017-12-23 Thread Michael Panzlaff 
To be applied on:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
Branch:
staging-next

This patch changes the indentation of the statements after case labels.
The linux coding guidelines do not explicitly mentiond this but pretty
much all existing code doesn't put any statements into the same line of
their belonging case labels. Therefore this adapts to the more usual style.

Please note that there is still a lot of > 80 character lines which will
cause checkpatch warnings. This patch does not intent to fix this
already existing issue.

Signed-off-by: Michael Panzlaff 
Signed-off-by: Tillmann Zipperer 
---
 drivers/staging/pi433/rf69.c | 246 ---
 1 file changed, 164 insertions(+), 82 deletions(-)

diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 8bc09e1..1375b49 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -111,11 +111,16 @@ static inline int rf69_read_mod_write(struct spi_device 
*spi, u8 reg, u8 mask, u
 int rf69_set_mode(struct spi_device *spi, enum mode mode)
 {
switch (mode) {
-   case transmit:return rf69_read_mod_write(spi, REG_OPMODE, 
MASK_OPMODE_MODE, OPMODE_MODE_TRANSMIT);
-   case receive: return rf69_read_mod_write(spi, REG_OPMODE, 
MASK_OPMODE_MODE, OPMODE_MODE_RECEIVE);
-   case synthesizer: return rf69_read_mod_write(spi, REG_OPMODE, 
MASK_OPMODE_MODE, OPMODE_MODE_SYNTHESIZER);
-   case standby: return rf69_read_mod_write(spi, REG_OPMODE, 
MASK_OPMODE_MODE, OPMODE_MODE_STANDBY);
-   case mode_sleep:  return rf69_read_mod_write(spi, REG_OPMODE, 
MASK_OPMODE_MODE, OPMODE_MODE_SLEEP);
+   case transmit:
+   return rf69_read_mod_write(spi, REG_OPMODE, MASK_OPMODE_MODE, 
OPMODE_MODE_TRANSMIT);
+   case receive:
+   return rf69_read_mod_write(spi, REG_OPMODE, MASK_OPMODE_MODE, 
OPMODE_MODE_RECEIVE);
+   case synthesizer:
+   return rf69_read_mod_write(spi, REG_OPMODE, MASK_OPMODE_MODE, 
OPMODE_MODE_SYNTHESIZER);
+   case standby:
+   return rf69_read_mod_write(spi, REG_OPMODE, MASK_OPMODE_MODE, 
OPMODE_MODE_STANDBY);
+   case mode_sleep:
+   return rf69_read_mod_write(spi, REG_OPMODE, MASK_OPMODE_MODE, 
OPMODE_MODE_SLEEP);
default:
dev_dbg(&spi->dev, "set: illegal input param");
return -EINVAL;
@@ -134,8 +139,10 @@ int rf69_set_data_mode(struct spi_device *spi, u8 
data_mode)
 int rf69_set_modulation(struct spi_device *spi, enum modulation modulation)
 {
switch (modulation) {
-   case OOK: return rf69_read_mod_write(spi, REG_DATAMODUL, 
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_OOK);
-   case FSK: return rf69_read_mod_write(spi, REG_DATAMODUL, 
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_FSK);
+   case OOK:
+   return rf69_read_mod_write(spi, REG_DATAMODUL, 
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_OOK);
+   case FSK:
+   return rf69_read_mod_write(spi, REG_DATAMODUL, 
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_FSK);
default:
dev_dbg(&spi->dev, "set: illegal input param");
return -EINVAL;
@@ -149,9 +156,12 @@ static enum modulation rf69_get_modulation(struct 
spi_device *spi)
currentValue = rf69_read_reg(spi, REG_DATAMODUL);
 
switch (currentValue & MASK_DATAMODUL_MODULATION_TYPE) {
-   case DATAMODUL_MODULATION_TYPE_OOK: return OOK;
-   case DATAMODUL_MODULATION_TYPE_FSK: return FSK;
-   default:return UNDEF;
+   case DATAMODUL_MODULATION_TYPE_OOK:
+   return OOK;
+   case DATAMODUL_MODULATION_TYPE_FSK:
+   return FSK;
+   default:
+   return UNDEF;
}
 }
 
@@ -161,19 +171,26 @@ int rf69_set_modulation_shaping(struct spi_device *spi,
switch (rf69_get_modulation(spi)) {
case FSK:
switch (mod_shaping) {
-   case SHAPING_OFF: return rf69_read_mod_write(spi, 
REG_DATAMODUL, MASK_DATAMODUL_MODULATION_SHAPE, 
DATAMODUL_MODULATION_SHAPE_NONE);
-   case SHAPING_1_0: return rf69_read_mod_write(spi, 
REG_DATAMODUL, MASK_DATAMODUL_MODULATION_SHAPE, DATAMODUL_MODULATION_SHAPE_1_0);
-   case SHAPING_0_5: return rf69_read_mod_write(spi, 
REG_DATAMODUL, MASK_DATAMODUL_MODULATION_SHAPE, DATAMODUL_MODULATION_SHAPE_0_5);
-   case SHAPING_0_3: return rf69_read_mod_write(spi, 
REG_DATAMODUL, MASK_DATAMODUL_MODULATION_SHAPE, DATAMODUL_MODULATION_SHAPE_0_3);
+   case SHAPING_OFF:
+   return rf69_read_mod_write(spi, REG_DATAMODUL, 
MASK_DATAMODUL_MODULATION_SHAPE, DATAMODUL_MODULATION_SHAPE_NONE);
+   case SHAPING_1_0:
+   return rf69_read_mod_write(spi, REG_DATAMODUL, 
MASK_DATAMODUL_MODULATION_SHAPE, DATAMODUL_MODULATION_SHAPE_1_0);
+

Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

2017-12-23 Thread Dou Liyang 

Hi Thomas,

At 12/23/2017 09:32 PM, Thomas Gleixner wrote:
[...]


The BUG_ON panic happens at line 147:
BUG_ON(!test_and_clear_bit(bit, cm->alloc_map));

I'm sure Thomas and Dou know it better than me.


I'll have a look after the holidays.



Merry Christmas!  :-)

I am trying to look into it.

Thanks,
dou


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

2017-12-23 Thread Alexandru Chirvasitu 
On Sat, Dec 23, 2017 at 02:32:52PM +0100, Thomas Gleixner wrote:
> On Sat, 23 Dec 2017, Dexuan Cui wrote:
> 
> > > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > > Sent: Friday, December 22, 2017 14:29
> > > 
> > > The output of that precise command run just now on a freshly-compiled
> > > copy of that commit is attached.
> > > 
> > > On Fri, Dec 22, 2017 at 09:31:28PM +, Dexuan Cui wrote:
> > > > > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > > > > Sent: Friday, December 22, 2017 06:21
> > > > >
> > > > > In the absence of logs, the best I can do at the moment is attach a
> > > > > picture of the screen I am presented with on the apic=debug boot
> > > > > attempt.
> > > > > Alex
> > > >
> > > > The panic happens in irq_matrix_assign_system+0x4e/0xd0 in your picture.
> > > > IMO we should find which line of code causes the panic. I suppose
> > > > "objdump -D kernel/irq/matrix.o" can help to do that.
> > > >
> > > > Thanks,
> > > > -- Dexuan
> > 
> > The BUG_ON panic happens at line 147:
> >BUG_ON(!test_and_clear_bit(bit, cm->alloc_map));
> > 
> > I'm sure Thomas and Dou know it better than me. 
> 
> I'll have a look after the holidays.
>

Thanks for that!

A quick follow-up on my inability to make kexec / kdump work in order
to perhaps produce better logs: I've done another bisect for that with
this result:

# first bad commit: [e802a51ede91350438c051da2f238f5e8c918ead] x86/idt: 
Consolidate IDT invalidation

I am quite certain this is the one for that issue. Its only parent is

# good: [8f55868f9e42fea56021b17421914b9e4fda4960] x86/idt: Remove unused 
set_trap_gate()

(i.e. one of the "good" commits I hit upon during the bisect).

On the core 2 duo machine I've been referring to e802a51 and later
commits simply return me to a regular BIOS boot when issuing either
kexec -e on a loaded crash kernel or crashing with echo c >
/proc/sysrq-trigger.


Alex
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: vc04_services: Prefer BUG_ON instead of if condition followed by BUG.

2017-12-23 Thread Stefan Wahren 
Hi Kishore,

> kishor...@techveda.org hat am 23. Dezember 2017 um 16:06 geschrieben:
> 
> 
> From: Kishore KP 
> 
> Use BUG_ON instead of if condition followed by BUG.
> Pointed out by Coccinelle.
> 
> Signed-off-by: Kishore KP 
> Signed-off-by: Suniel Mahesh 
> ---
> Note:
> - Patch was compile tested and built(ARCH=arm) on linux-next
>   (latest).
> - No build issues reported.
> ---
>  drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git 
> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c 
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> index 315b49c..7116f61 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> @@ -224,8 +224,7 @@ int vchiq_platform_init(struct platform_device *pdev, 
> VCHIQ_STATE_T *state)
>  
>   platform_state   = (struct vchiq_2835_state *)state->platform_state;
>  
> - if (!platform_state->inited)
> - BUG();
> + BUG_ON(!platform_state->inited);
>  

vchiq isn't critical so i prefer WARN_ON_ONCE() here.

Thanks
Stefan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 00/27] kill devm_ioremap_nocache

2017-12-23 Thread Guenter Roeck 

On 12/23/2017 05:48 AM, Greg KH wrote:

On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:

Hi all,

When I tried to use devm_ioremap function and review related code, I found
devm_ioremap and devm_ioremap_nocache is almost the same with each other,
except one use ioremap while the other use ioremap_nocache.


For all arches?  Really?  Look at MIPS, and x86, they have different
functions.



Both mips and x86 end up mapping the same function, but other arches don't.
mn10300 is one where ioremap and ioremap_nocache are definitely different.

Guenter


While ioremap's
default function is ioremap_nocache, so devm_ioremap_nocache also have the
same function with devm_ioremap, which can just be killed to reduce the size
of devres.o(from 20304 bytes to 18992 bytes in my compile environment).

I have posted two versions, which use macro instead of function for
devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
devm_ioremap_nocache for no need to keep a macro around for the duplicate
thing. So here comes v3 and please help to review.


I don't think this can be done, what am I missing?  These functions are
not identical, sorry for missing that before.

thanks,

greg k-h



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: wlan-ng: hfa384x_usb: fixed two line limit coding style issues

2017-12-23 Thread Andy Pusch 
Fixed two coding style issues.

Signed-off-by: Andy Pusch 
---
 drivers/staging/wlan-ng/hfa384x_usb.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c 
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 197f5a914e8f..d6df35e1745c 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -2457,7 +2457,8 @@ int hfa384x_drvr_start(struct hfa384x *hw)
 * ok
 */
result =
-   usb_get_std_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_in, 
&status);
+   usb_get_std_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_in,
+  &status);
if (result < 0) {
netdev_err(hw->wlandev->netdev, "Cannot get bulk in endpoint 
status.\n");
goto done;
@@ -2466,7 +2467,8 @@ int hfa384x_drvr_start(struct hfa384x *hw)
netdev_err(hw->wlandev->netdev, "Failed to reset bulk in 
endpoint.\n");
 
result =
-   usb_get_std_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_out, 
&status);
+   usb_get_std_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_out,
+  &status);
if (result < 0) {
netdev_err(hw->wlandev->netdev, "Cannot get bulk out endpoint 
status.\n");
goto done;
-- 
2.15.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: vc04_services: Fix platform_no_drv_owner.cocci warnings.

2017-12-23 Thread kishore . p 
From: Kishore KP 

Removed .owner field initialization, platform core does it automatically.
Pointed out by Coccinelle.

Signed-off-by: Kishore KP 
Signed-off-by: Suniel Mahesh 
---
Note:
- Patch was compile tested and built(ARCH=arm) on linux-next
  (latest).
- No build issues reported.
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
index 8f2d508..50a5f29 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.c
@@ -443,7 +443,6 @@ static int snd_bcm2835_alsa_resume(struct platform_device 
*pdev)
 #endif
.driver = {
.name = "bcm2835_audio",
-   .owner = THIS_MODULE,
.of_match_table = snd_bcm2835_of_match_table,
},
 };
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: vc04_services: Prefer BUG_ON instead of if condition followed by BUG.

2017-12-23 Thread kishore . p 
From: Kishore KP 

Use BUG_ON instead of if condition followed by BUG.
Pointed out by Coccinelle.

Signed-off-by: Kishore KP 
Signed-off-by: Suniel Mahesh 
---
Note:
- Patch was compile tested and built(ARCH=arm) on linux-next
  (latest).
- No build issues reported.
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 315b49c..7116f61 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -224,8 +224,7 @@ int vchiq_platform_init(struct platform_device *pdev, 
VCHIQ_STATE_T *state)
 
platform_state   = (struct vchiq_2835_state *)state->platform_state;
 
-   if (!platform_state->inited)
-   BUG();
+   BUG_ON(!platform_state->inited);
 
return &platform_state->arm_state;
 }
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 00/27] kill devm_ioremap_nocache

2017-12-23 Thread Greg KH 
On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
> Hi all,
> 
> When I tried to use devm_ioremap function and review related code, I found
> devm_ioremap and devm_ioremap_nocache is almost the same with each other,
> except one use ioremap while the other use ioremap_nocache.

For all arches?  Really?  Look at MIPS, and x86, they have different
functions.

> While ioremap's
> default function is ioremap_nocache, so devm_ioremap_nocache also have the
> same function with devm_ioremap, which can just be killed to reduce the size
> of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
> 
> I have posted two versions, which use macro instead of function for
> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
> devm_ioremap_nocache for no need to keep a macro around for the duplicate
> thing. So here comes v3 and please help to review.

I don't think this can be done, what am I missing?  These functions are
not identical, sorry for missing that before.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 27/27] devres: kill devm_ioremap_nocache

2017-12-23 Thread Greg KH 
On Sat, Dec 23, 2017 at 07:02:59PM +0800, Yisheng Xie wrote:
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -44,35 +44,6 @@ void __iomem *devm_ioremap(struct device *dev, 
> resource_size_t offset,
>  EXPORT_SYMBOL(devm_ioremap);
>  
>  /**
> - * devm_ioremap_nocache - Managed ioremap_nocache()
> - * @dev: Generic device to remap IO address for
> - * @offset: Resource address to map
> - * @size: Size of map
> - *
> - * Managed ioremap_nocache().  Map is automatically unmapped on driver
> - * detach.
> - */
> -void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t 
> offset,
> -resource_size_t size)
> -{
> - void __iomem **ptr, *addr;
> -
> - ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
> - if (!ptr)
> - return NULL;
> -
> - addr = ioremap_nocache(offset, size);

Wait, devm_ioremap() calls ioremap(), not ioremap_nocache(), are you
_SURE_ that these are all identical?  For all arches?  If so, then
ioremap_nocache() can also be removed, right?

In my quick glance, I don't think you can do this series at all :(

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

2017-12-23 Thread Thomas Gleixner 
On Sat, 23 Dec 2017, Dexuan Cui wrote:

> > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > Sent: Friday, December 22, 2017 14:29
> > 
> > The output of that precise command run just now on a freshly-compiled
> > copy of that commit is attached.
> > 
> > On Fri, Dec 22, 2017 at 09:31:28PM +, Dexuan Cui wrote:
> > > > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com]
> > > > Sent: Friday, December 22, 2017 06:21
> > > >
> > > > In the absence of logs, the best I can do at the moment is attach a
> > > > picture of the screen I am presented with on the apic=debug boot
> > > > attempt.
> > > > Alex
> > >
> > > The panic happens in irq_matrix_assign_system+0x4e/0xd0 in your picture.
> > > IMO we should find which line of code causes the panic. I suppose
> > > "objdump -D kernel/irq/matrix.o" can help to do that.
> > >
> > > Thanks,
> > > -- Dexuan
> 
> The BUG_ON panic happens at line 147:
>BUG_ON(!test_and_clear_bit(bit, cm->alloc_map));
> 
> I'm sure Thomas and Dou know it better than me. 

I'll have a look after the holidays.

Thanks,

tglx
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3 00/27] kill devm_ioremap_nocache

2017-12-23 Thread Yisheng Xie 
Hi all,

When I tried to use devm_ioremap function and review related code, I found
devm_ioremap and devm_ioremap_nocache is almost the same with each other,
except one use ioremap while the other use ioremap_nocache. While ioremap's
default function is ioremap_nocache, so devm_ioremap_nocache also have the
same function with devm_ioremap, which can just be killed to reduce the size
of devres.o(from 20304 bytes to 18992 bytes in my compile environment).

I have posted two versions, which use macro instead of function for
devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
devm_ioremap_nocache for no need to keep a macro around for the duplicate
thing. So here comes v3 and please help to review.

Thanks so much!
Yisheng Xie

[1] https://lkml.org/lkml/2017/11/20/135
[2] https://lkml.org/lkml/2017/11/25/21

Yisheng Xie (27):
  ASOC: replace devm_ioremap_nocache with devm_ioremap
  spi: replace devm_ioremap_nocache with devm_ioremap
  staging: replace devm_ioremap_nocache with devm_ioremap
  ipack: replace devm_ioremap_nocache with devm_ioremap
  media: replace devm_ioremap_nocache with devm_ioremap
  gpio: replace devm_ioremap_nocache with devm_ioremap
  mmc: replace devm_ioremap_nocache with devm_ioremap
  PCI: replace devm_ioremap_nocache with devm_ioremap
  platform/x86: replace devm_ioremap_nocache with devm_ioremap
  tty: replace devm_ioremap_nocache with devm_ioremap
  video: replace devm_ioremap_nocache with devm_ioremap
  rtc: replace devm_ioremap_nocache with devm_ioremap
  char: replace devm_ioremap_nocache with devm_ioremap
  mtd: nand: replace devm_ioremap_nocache with devm_ioremap
  dmaengine: replace devm_ioremap_nocache with devm_ioremap
  ata: replace devm_ioremap_nocache with devm_ioremap
  irqchip: replace devm_ioremap_nocache with devm_ioremap
  pinctrl: replace devm_ioremap_nocache with devm_ioremap
  drm: replace devm_ioremap_nocache with devm_ioremap
  regulator: replace devm_ioremap_nocache with devm_ioremap
  watchdog: replace devm_ioremap_nocache with devm_ioremap
  tools/testing/nvdimm: replace devm_ioremap_nocache with devm_ioremap
  MIPS: pci: replace devm_ioremap_nocache with devm_ioremap
  can: replace devm_ioremap_nocache with devm_ioremap
  wireless: replace devm_ioremap_nocache with devm_ioremap
  ethernet: replace devm_ioremap_nocache with devm_ioremap
  devres: kill devm_ioremap_nocache

 Documentation/driver-model/devres.txt   |  1 -
 arch/mips/pci/pci-ar2315.c  |  3 +--
 drivers/ata/pata_arasan_cf.c|  3 +--
 drivers/ata/pata_octeon_cf.c|  9 
 drivers/ata/pata_rb532_cf.c |  2 +-
 drivers/char/hw_random/bcm63xx-rng.c|  3 +--
 drivers/char/hw_random/octeon-rng.c | 10 -
 drivers/dma/altera-msgdma.c |  3 +--
 drivers/dma/sprd-dma.c  |  4 ++--
 drivers/gpio/gpio-ath79.c   |  3 +--
 drivers/gpio/gpio-em.c  |  6 ++---
 drivers/gpio/gpio-htc-egpio.c   |  4 ++--
 drivers/gpio/gpio-xgene.c   |  3 +--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c   |  2 +-
 drivers/gpu/drm/sti/sti_dvo.c   |  3 +--
 drivers/gpu/drm/sti/sti_hda.c   |  4 ++--
 drivers/gpu/drm/sti/sti_hdmi.c  |  2 +-
 drivers/gpu/drm/sti/sti_tvout.c |  2 +-
 drivers/gpu/drm/sti/sti_vtg.c   |  2 +-
 drivers/ipack/devices/ipoctal.c | 13 +--
 drivers/irqchip/irq-renesas-intc-irqpin.c   |  4 ++--
 drivers/media/platform/tegra-cec/tegra_cec.c|  4 ++--
 drivers/mmc/host/sdhci-acpi.c   |  3 +--
 drivers/mtd/nand/fsl_upm.c  |  4 ++--
 drivers/net/can/sja1000/sja1000_platform.c  |  4 ++--
 drivers/net/ethernet/altera/altera_tse_main.c   |  3 +--
 drivers/net/ethernet/ethoc.c|  8 +++
 drivers/net/ethernet/lantiq_etop.c  |  4 ++--
 drivers/net/ethernet/ti/netcp_core.c|  2 +-
 drivers/net/wireless/ath/ath9k/ahb.c|  2 +-
 drivers/pci/dwc/pci-dra7xx.c|  2 +-
 drivers/pinctrl/bcm/pinctrl-ns2-mux.c   |  2 +-
 drivers/pinctrl/bcm/pinctrl-nsp-mux.c   |  4 ++--
 drivers/pinctrl/freescale/pinctrl-imx1-core.c   |  2 +-
 drivers/pinctrl/pinctrl-amd.c   |  4 ++--
 drivers/platform/x86/intel_pmc_core.c   |  5 ++---
 drivers/regulator/ti-abb-regulator.c|  6 ++---
 drivers/rtc/rtc-sh.c|  4 ++--
 drivers/spi/spi-jcore.c |  3 +--
 drivers/staging/fsl-mc/bus/mc-io.c  |  8 +++
 drivers/tty/mips_ejtag_fdc.c|  4 ++--
 drivers/tty/serial/8250/8250_omap.c |  3 +--
 drivers/tty/serial/lantiq.c |  3 +--
 drivers/tty/serial/meson_uart.c

[PATCH v3 03/27] staging: replace devm_ioremap_nocache with devm_ioremap

2017-12-23 Thread Yisheng Xie 
Default ioremap is ioremap_nocache, so devm_ioremap has the same
function with devm_ioremap_nocache, which can just be killed to
save the size of devres.o.

This patch is to use use devm_ioremap instead of devm_ioremap_nocache,
which should not have any function change but prepare for killing
devm_ioremap_nocache.

Cc: Greg Kroah-Hartman 
Cc: de...@driverdev.osuosl.org
Signed-off-by: Yisheng Xie 
---
 drivers/staging/fsl-mc/bus/mc-io.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/mc-io.c 
b/drivers/staging/fsl-mc/bus/mc-io.c
index f65c23c..cd13521 100644
--- a/drivers/staging/fsl-mc/bus/mc-io.c
+++ b/drivers/staging/fsl-mc/bus/mc-io.c
@@ -134,12 +134,12 @@ int __must_check fsl_create_mc_io(struct device *dev,
return -EBUSY;
}
 
-   mc_portal_virt_addr = devm_ioremap_nocache(dev,
-  mc_portal_phys_addr,
-  mc_portal_size);
+   mc_portal_virt_addr = devm_ioremap(dev,
+  mc_portal_phys_addr,
+  mc_portal_size);
if (!mc_portal_virt_addr) {
dev_err(dev,
-   "devm_ioremap_nocache failed for MC portal %pa\n",
+   "devm_ioremap failed for MC portal %pa\n",
&mc_portal_phys_addr);
return -ENXIO;
}
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] drivers: lustre: obdclass: simplify unregister_shrinker() usage

2017-12-23 Thread Aliaksei Karaliou 
lu_global_fini() explicitly uses knowledge about shrinker's
internals to make decision about calling of unregister_shrinker().
Now this check was integrated into unregister_shrinker(),
so it is safe to call it against unregistered shrinker.

Signed-off-by: Aliaksei Karaliou 
---
 drivers/staging/lustre/lustre/obdclass/lu_object.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c 
b/drivers/staging/lustre/lustre/obdclass/lu_object.c
index 8e2e6b89e494..2719abbff85f 100644
--- a/drivers/staging/lustre/lustre/obdclass/lu_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c
@@ -1977,8 +1977,7 @@ int lu_global_init(void)
  */
 void lu_global_fini(void)
 {
-   if (lu_site_shrinker.nr_deferred)
-   unregister_shrinker(&lu_site_shrinker);
+   unregister_shrinker(&lu_site_shrinker);
lu_context_key_degister(&lu_global_key);
 
/*
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3 27/27] devres: kill devm_ioremap_nocache

2017-12-23 Thread Yisheng Xie 
Now, nobody use devm_ioremap_nocache anymore, can it can just be
removed. After this patch the size of devres.o will be reduced from
20304 bytes to 18992 bytes.

Suggested-by: Greg KH 
Signed-off-by: Yisheng Xie 
---
 Documentation/driver-model/devres.txt   |  1 -
 include/linux/io.h  |  2 --
 lib/devres.c| 29 -
 scripts/coccinelle/free/devm_free.cocci |  2 --
 4 files changed, 34 deletions(-)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index c180045..c3fddb5 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -292,7 +292,6 @@ IOMAP
   devm_ioport_map()
   devm_ioport_unmap()
   devm_ioremap()
-  devm_ioremap_nocache()
   devm_ioremap_wc()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
   devm_iounmap()
diff --git a/include/linux/io.h b/include/linux/io.h
index 32e30e8..a9c7270 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -75,8 +75,6 @@ static inline void devm_ioport_unmap(struct device *dev, void 
__iomem *addr)
 
 void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
   resource_size_t size);
-void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
-  resource_size_t size);
 void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
   resource_size_t size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
diff --git a/lib/devres.c b/lib/devres.c
index 5f2aedd..f818fcf 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -44,35 +44,6 @@ void __iomem *devm_ioremap(struct device *dev, 
resource_size_t offset,
 EXPORT_SYMBOL(devm_ioremap);
 
 /**
- * devm_ioremap_nocache - Managed ioremap_nocache()
- * @dev: Generic device to remap IO address for
- * @offset: Resource address to map
- * @size: Size of map
- *
- * Managed ioremap_nocache().  Map is automatically unmapped on driver
- * detach.
- */
-void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
-  resource_size_t size)
-{
-   void __iomem **ptr, *addr;
-
-   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
-   if (!ptr)
-   return NULL;
-
-   addr = ioremap_nocache(offset, size);
-   if (addr) {
-   *ptr = addr;
-   devres_add(dev, ptr);
-   } else
-   devres_free(ptr);
-
-   return addr;
-}
-EXPORT_SYMBOL(devm_ioremap_nocache);
-
-/**
  * devm_ioremap_wc - Managed ioremap_wc()
  * @dev: Generic device to remap IO address for
  * @offset: Resource address to map
diff --git a/scripts/coccinelle/free/devm_free.cocci 
b/scripts/coccinelle/free/devm_free.cocci
index c990d2c..36b8752 100644
--- a/scripts/coccinelle/free/devm_free.cocci
+++ b/scripts/coccinelle/free/devm_free.cocci
@@ -51,8 +51,6 @@ expression x;
 |
  x = devm_ioremap(...)
 |
- x = devm_ioremap_nocache(...)
-|
  x = devm_ioport_map(...)
 )
 
-- 
1.8.3.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel