Re: [PATCH] tcp: sysctl to disable TCP simultaneous connect

2013-02-14 Thread Willy Tarreau
Hi Eric,

On Thu, Feb 14, 2013 at 11:10:46PM -0800, Eric W. Biederman wrote:
> Kees Cook  writes:
> 
> > On Thu, Feb 14, 2013 at 9:30 PM, Eric W. Biederman
> >  wrote:
> >> Kees Cook  writes:
> >>
> >>> The patch would not break it -- it defaults the sysctl to staying enabled.
> >>>
> >>> If you mean the documentation should be updated, sure, that's easy to do.
> >>>
> >>> David: I know you aren't a fan of this patch, but I'd like to try to
> >>> convince you. :) This leaves the feature enabled and add a toggle for
> >>> systems (like Chrome OS) that don't want to risk this DoS at all.
> >>> There are so very many other toggle, I don't see why this one would be
> >>> a problem to add.
> >>
> >> Chrome OS has no plans to implement webrtc?  Last I had read that
> >> support had been added to the release versions of Chrome, and was in the
> >> development builds of firefox.  I really don't belive that there are
> >> many systems that don't intend to run a web browser.
> >
> > I haven't looked at the internals of webrtc. Are you implying some
> > feature in it relies on the TCP simultaneous connect?
> 
> I am saying that yes.
> 
> webrtc is built on ICE (interactivity connectivity establishment).  ICE
> support for TCP (RFC6544) uses TCP simultaneous connect.  webrtc
> supports tcp connections.

Then I suspect that a large number of firewalls will need updates after
significant rework for this proposal to succeed. I'm not saying this will
not eventually happen, but there are significant risks associated with
this feature.  Netfilter had this in the window tracking patches around
2002-2003 and this had to be reverted because a client was able to establish
complete connections by sending SYN-SYN/ACK-ACK itself. Other products will
fall through these cracks.

And last but not least, it's the only behaviour in TCP which allows a
random attacker to prevent a connection from establishing by guessing
only a 16-bit port, regardless of any sequence number. Considering how
we've been bothered by people who considered that our sequence numbers
were not random enough, I already expect that the absolute lack of need
of a sequence number will bring new funny articles.

Back then, I did a PoC which permanently prevented an anti-virus proxy
from establishing any connection to its update server, and it did not
require a lot of traffic obviously. People running such proxies probably
don't need webrtc with its assorted lot of issues.

I'm not advocating for pushing the patch, I understand it's not desired.
I just want to ensure that people understand what simultaneous connect
means in terms of DoS for a feature which is rarely used and rarely
technically possible at all.

Regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: max77686: add missing variable initialization

2013-02-14 Thread Jingoo Han
Fixed build warning as below:

drivers/rtc/rtc-max77686.c: In function 'max77686_rtc_update':
drivers/rtc/rtc-max77686.c:147:6: warning: 'data' may be used uninitialized in 
this function [-Wuninitialized]

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-max77686.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index abe27c0..2634fed 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -133,7 +133,7 @@ static int max77686_rtc_update(struct max77686_rtc_info 
*info,
enum MAX77686_RTC_OP op)
 {
int ret;
-   unsigned int data;
+   unsigned int data = 0;
 
switch (op) {
case MAX77686_RTC_WRITE:
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] sched: The removal of idle_balance()

2013-02-14 Thread Joonsoo Kim
Hello, Steven.

On Fri, Feb 15, 2013 at 01:13:39AM -0500, Steven Rostedt wrote:

>  Performance counter stats for '/work/c/hackbench 500' (100 runs):
> 
>  199820.045583 task-clock#8.016 CPUs utilized 
>( +-  5.29% ) [100.00%]
>  3,594,264 context-switches  #0.018 M/sec 
>( +-  5.94% ) [100.00%]
>352,240 cpu-migrations#0.002 M/sec 
>( +-  3.31% ) [100.00%]
>  1,006,732 page-faults   #0.005 M/sec 
>( +-  0.56% )
>293,801,912,874 cycles#1.470 GHz   
>( +-  4.20% ) [100.00%]
>261,808,125,109 stalled-cycles-frontend   #   89.11% frontend cycles idle  
>( +-  4.38% ) [100.00%]
> stalled-cycles-backend  
>135,521,344,089 instructions  #0.46  insns per cycle   
>  
>  #1.93  stalled cycles per 
> insn  ( +-  4.37% ) [100.00%]
> 26,198,116,586 branches  #  131.109 M/sec 
>( +-  4.59% ) [100.00%]
>115,326,812 branch-misses #0.44% of all branches   
>( +-  4.12% )
> 
>   24.929136087 seconds time elapsed   
>( +-  5.31% )
> 
>  Performance counter stats for '/work/c/hackbench 500' (100 runs):
> 
>   98258.962617 task-clock#7.998 CPUs utilized 
>( +- 12.12% ) [100.00%]
>  2,572,651 context-switches  #0.026 M/sec 
>( +-  9.35% ) [100.00%]
>224,004 cpu-migrations#0.002 M/sec 
>( +-  5.01% ) [100.00%]
>913,813 page-faults   #0.009 M/sec 
>( +-  0.71% )
>215,927,081,108 cycles#2.198 GHz   
>( +-  5.48% ) [100.00%]
>189,246,626,321 stalled-cycles-frontend   #   87.64% frontend cycles idle  
>( +-  6.07% ) [100.00%]
> stalled-cycles-backend  
>102,965,954,824 instructions  #0.48  insns per cycle   
>  
>  #1.84  stalled cycles per 
> insn  ( +-  5.40% ) [100.00%]
> 19,280,914,558 branches  #  196.226 M/sec 
>( +-  5.89% ) [100.00%]
> 87,284,617 branch-misses #0.45% of all branches   
>( +-  5.06% )
> 
>   12.285025160 seconds time elapsed   
>( +- 12.14% )

IMHO, cycles is somewhat strange.
Why one is 1.470 GHz, other is 2.198 GHz? 

In my quick test, I get below result.

- Before Patch
Permance counter stats for 'perf bench sched messaging -g 300' (10 runs):

  40847.488740 task-clock#3.232 CPUs utilized   
 ( +-  1.24% )
   511,070 context-switches  #0.013 M/sec   
 ( +-  7.28% )
   117,882 cpu-migrations#0.003 M/sec   
 ( +-  5.14% )
 1,360,501 page-faults   #0.033 M/sec   
 ( +-  0.12% )
   118,534,394,180 cycles#2.902 GHz 
 ( +-  1.23% ) [50.70%]
stalled-cycles-frontend 
stalled-cycles-backend  
46,217,340,271 instructions  #0.39  insns per cycle 
 ( +-  0.56% ) [76.93%]
 8,592,447,548 branches  #  210.354 M/sec   
 ( +-  0.75% ) [75.50%]
   273,367,481 branch-misses #3.18% of all branches 
 ( +-  0.26% ) [75.49%]

  12.639049245 seconds time elapsed 
 ( +-  2.29% )

- After Patch
 Performance counter stats for 'perf bench sched messaging -g 300' (10 runs):

  42053.008632 task-clock#2.932 CPUs utilized   
 ( +-  0.91% )
   672,759 context-switches  #0.016 M/sec   
 ( +-  2.76% )
83,374 cpu-migrations#0.002 M/sec   
 ( +-  4.46% )
 1,362,900 page-faults   #0.032 M/sec   
 ( +-  0.20% )
   121,457,601,848 cycles#2.888 GHz 
 ( +-  0.93% ) [50.75%]
stalled-cycles-frontend 
stalled-cycles-backend  
47,854,828,552 instructions  #0.39  insns per cycle 
 ( +-  0.36% ) [77.09%]
 8,981,553,714 branches  #  213.577 M/sec   
 ( +-  0.42% ) [75.41%]
   274,229,438 branch-misses #3.05% of all branches 
 ( +-  0.20% ) [75.44%]

  14.340330678 seconds time elapsed 
 ( +-  1.79% )

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  

Konto certifikat har gått ut på 2013/13/02

2013-02-14 Thread Jens.H.Hultberg
Ditt e-postkonto certifikat löpte ut den 2013/13/02, kan detta avbryta din 
e-postleverans konfiguration och kontoinställningar POP, sida felmeddelande när 
du skickar meddelandet.

För att åter nya din webbmail certifikat, ta en sekund att uppdatera dina 
uppgifter genom att följa referens länken nedan:
https://docs.google.com/forms/d/1FWf7Z7ZZoIrEe5XCB9w40zvlwgWKtq89sHon6WQZrUE/viewform

När informationen matcher vad som är på vår skiva, kommer ditt konto att 
fungera som vanligt efter kontrollbesöket är processen och webbmail certifikat 
kommer att förnyades.

Med vänliga hälsningar,
Mail Service Team.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pt_regs leak into userspace (was Re: [PATCH v3 20/71] ARC: Signal handling)

2013-02-14 Thread Vineet Gupta
On Friday 15 February 2013 12:53 PM, Jonas Bonn wrote:
> On 11 February 2013 15:07, Al Viro  wrote:
>
>> I'd suggest asking itanic folks; they do *not* put callee-saved stuff into
>> sigcontext.  AFAICS, they don't have setcontext() implemented as a syscall
>> at all - it's done as sigprocmask() + doing to callee-saved registers what
>> longjmp() does.
>
> Just to round off this discussion, after giving it some more thought I
> agree that the case where you would need callee-saved registers
> restored is probably rather pathological.  Any sane use of
> get/set/swapcontext is manageable without this.
>
> So, Vineet, I'm now convinced your approach is sound.  I will probably
> amend the OpenRISC arch to behave similarly.  Consider your entire
> patch Acked now.

I'll add your ack to the the signal handling patch as the contention was 
primarily
on sigcontext bits.

Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/1] ARM: OMAP4: Add OMAP4 Blaze Tablet support

2013-02-14 Thread Jon Hunter

On 02/13/2013 05:28 PM, Ruslan Bilovol wrote:
> Hi Tony, Jon,
> 
> On Mon, Feb 11, 2013 at 9:00 PM, Tony Lindgren  wrote:
>> * Jon Hunter  [130211 10:58]:
>>>
>>> Please note that the blaze is derived from the omap4-sdp board and so I
>>> would hope that we can use the existing for sdp dts and board file for
>>> blaze. In fact this is what I do today for basic booting.
>>>
>>> So unless there is some feature on the blaze that is not compatible with
>>> the original sdp, we should just use the sdp dts.
>>
>> Sounds like we need some common .dts file and separate files
>> for sdp, blaze and tablet that include the common .dts file?
>>
>> There's a different LCD panel at least between blaze and the
>> tablet.
> 
> Please note, that, although 'Blaze' board is very close to 'SDP' board,
> there are quite big differences comparing to 'Blaze Tablet' board.
> At least:
>  - LCD panels
>  - touchscreen controllers
>  - LEDs
>  - Keypad (on 'Blaze') / gpio keys (on 'Blaze Tablet')
>  - Sensors
>  - HS USB Host related stuff

SDP also has usb host too (but yes blaze does not).

>  - cameras (there is no embedded cameras on 'Blaze Tablet' board)
> 
> As per my point of view, next should be done:
> 1) Add the DTS file for BlazeTablet board
> 2) Figure out what is common for both and move it to some common file
> (if that makes sense)
> 
> I'm currently working on step '#1'. So after that step #2 should not
> be an issue for us.

Sounds good. They all use the same processor boards and so may be that
can be common in DT and we can have a dtsi for that.

Cheers
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: [v3.8 Regression] watchdog: sp5100_tco: Add SB8x0 chipset support

2013-02-14 Thread Wim Van Sebroeck
Hi Joseph,

> A bug was opened against the Ubuntu kernel[0].  It was found that 
> reverting the following commit resolved this bug:
> 
> commit 740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104
> Author: Takahisa Tanaka 
> Date:   Sun Dec 2 14:33:18 2012 +0900
> 
> watchdog: sp5100_tco: Add SB8x0 chipset support
> 
> 
> The regression was introduced as of v3.8-rc1.
> 
> I see that you are the author of this patch, so I wanted to run this by 
> you.  I was thinking of requesting a revert for v3.8, but I wanted to 
> get your feedback first.

Please check out the attached patches first (They are allready in linux-next).

Other references:
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176

Kind regards,
Wim.

>From mc74h...@gmail.com Mon Jan 14 03:02:20 2013
Return-path: 
Envelope-to: w...@infomag.iguana.be
Delivery-date: Mon, 14 Jan 2013 03:02:20 +0100
Received: from ylaen.iguana.be ([178.21.116.169])
by spo001.leaseweb.com with esmtp (Exim 4.50)
id 1TuZNU-0006Zi-0P
for w...@infomag.iguana.be; Mon, 14 Jan 2013 03:02:20 +0100
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45])
by ylaen.iguana.be (Postfix) with ESMTP id 939FC174278
for ; Mon, 14 Jan 2013 03:02:19 +0100 (CET)
Received: by mail-pb0-f45.google.com with SMTP id mc8so1875722pbc.32
for ; Sun, 13 Jan 2013 18:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:from:to:cc:subject:date:message-id:x-mailer;
bh=Al12X3CF48UZXAYSA0AbzpLWDndmh59rkg9CMqG3eKs=;
b=BN3M1HJsUrmYnOe3KiT2w9jZTOWHevYNdIbLumjQWul8MbPVI1WDie98dgoG21C18P
 BuaHoo82fmCZBViD0qyuQz0RI0vySln5olsfpBsCKJVWTFDSAAg/kysHmcqOVp6sWpDI
 VPSe22vIVgxiNtqK0BdwGLjyvhQJ7Cgnv/3CrIa4h1HUfP8hKMwy/9V6SCe4VRpt7bOZ
 ZqTxpMfQ95pesNTKJuZEx2vqL5LM2WMVqUhneVR1dG4ceFTbOZ3xF57waoUEszGFlrmq
 0owzHTSi1BVF1wlxEfYXPuSie/gS2Yl9AGqHoaXm3DN3aSXwXbqnIK5VdUi/3Cir7CUK
 zj3Q==
X-Received: by 10.66.83.165 with SMTP id r5mr229452746pay.3.1358128938114;
Sun, 13 Jan 2013 18:02:18 -0800 (PST)
Received: from localhost (p7204-ipngn2902marunouchi.tokyo.ocn.ne.jp. 
[180.47.244.204])
by mx.google.com with ESMTPS id qh4sm7226051pbb.9.2013.01.13.18.02.14
(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
Sun, 13 Jan 2013 18:02:16 -0800 (PST)
From: Takahisa Tanaka 
To: linux-watch...@vger.kernel.org
Cc: Wim Van Sebroeck ,
Paul Menzel ,
Arkadiusz Miskiewicz ,
Bjorn Helgaas ,
Andrew Morton ,
Jonathan Nieder ,
linux-kernel@vger.kernel.org,
Florian Mickler ,
Takahisa Tanaka 
Subject: [PATCH 1/2] watchdog: sp5100_tco: Fix wrong indirect I/O access for 
getting value of reserved bits
Date: Mon, 14 Jan 2013 11:01:57 +0900
Message-Id: <1358128918-4415-1-git-send-email-mc74h...@gmail.com>
X-Mailer: git-send-email 1.7.11.7
Content-Length: 1656
Lines: 42

In case of SB800 or later chipset and re-programming MMIO address(*),
sp5100_tco module may read incorrect value of reserved bit, because the module
reads a value from an incorrect I/O address. However, this bug doesn't cause
a problem, because when re-programming MMIO address, by chance the module
writes zero (this is BIOS's default value) to the low three bits of register.
* In most cases, PC with SB8x0 or later chipset doesn't need to re-programming
  MMIO address, because such PC can enable AcpiMmio and can use 0xfed80b00 for
  watchdog register base address.

This patch fixes this bug.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176
Signed-off-by: Takahisa Tanaka 
Signed-off-by: Wim Van Sebroeck 
---
 drivers/watchdog/sp5100_tco.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 2b0e000..5dfe86e 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -500,14 +500,15 @@ static unsigned char sp5100_tco_setupdevice(void)
/* Restore to the low three bits, if chipset is SB8x0(or later) */
if (sp5100_tco_pci->revision >= 0x40) {
u8 reserved_bit;
-   reserved_bit = inb(base_addr) & 0x7;
+   outb(base_addr+0, index_reg);
+   reserved_bit = inb(data_reg) & 0x7;
val |= (u32)reserved_bit;
}
 
/* Re-programming the watchdog timer base address */
outb(base_addr+0, index_reg);
/* Low three bits of BASE are reserved */
-   outb((val >>  0) & 0xf8, data_reg);
+   outb((val >>  0) & 0xff, data_reg);
outb(base_addr+1, index_reg);
outb((val >>  8) & 0xff, data_reg);
outb(base_addr+2, index_reg);
-- 
1.7.11.7


>From mc74h...@gmail.com Mon Jan 14 03:02:31 2013
Return-path: 
Envelope-to: w...@infomag.iguana.be
Delivery-date: Mon, 14 Jan 2013 03:02:31 +0100
Received: from 

[PATCH V3 11/11] rtc: rtc-cmos: use dev_warn()/dev_dbg() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

No changes since v2:

 drivers/rtc/rtc-cmos.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 9deb9e4..af97c94 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -706,7 +706,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, 
int rtc_irq)
rtc_cmos_int_handler = hpet_rtc_interrupt;
err = hpet_register_irq_handler(cmos_interrupt);
if (err != 0) {
-   printk(KERN_WARNING "hpet_register_irq_handler "
+   dev_warn(dev, "hpet_register_irq_handler "
" failed in rtc_init().");
goto cleanup1;
}
@@ -731,8 +731,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, 
int rtc_irq)
goto cleanup2;
}
 
-   pr_info("%s: %s%s, %zd bytes nvram%s\n",
-   dev_name(_rtc.rtc->dev),
+   dev_info(dev, "%s%s, %zd bytes nvram%s\n",
!is_valid_irq(rtc_irq) ? "no alarms" :
cmos_rtc.mon_alrm ? "alarms up to one year" :
cmos_rtc.day_alrm ? "alarms up to one month" :
@@ -820,8 +819,7 @@ static int cmos_suspend(struct device *dev)
enable_irq_wake(cmos->irq);
}
 
-   pr_debug("%s: suspend%s, ctrl %02x\n",
-   dev_name(_rtc.rtc->dev),
+   dev_dbg(dev, "suspend%s, ctrl %02x\n",
(tmp & RTC_AIE) ? ", alarm may wake" : "",
tmp);
 
@@ -876,9 +874,7 @@ static int cmos_resume(struct device *dev)
spin_unlock_irq(_lock);
}
 
-   pr_debug("%s: resume, ctrl %02x\n",
-   dev_name(_rtc.rtc->dev),
-   tmp);
+   dev_dbg(dev, "resume, ctrl %02x\n", tmp);
 
return 0;
 }
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 10/11] rtc: rtc-pcf8583: use dev_warn() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

Changes since v2:
- Remove redundant prefix

 drivers/rtc/rtc-pcf8583.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-pcf8583.c b/drivers/rtc/rtc-pcf8583.c
index 3415b8f..5f97c61 100644
--- a/drivers/rtc/rtc-pcf8583.c
+++ b/drivers/rtc/rtc-pcf8583.c
@@ -185,8 +185,8 @@ static int pcf8583_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
if (ctrl & (CTRL_STOP | CTRL_HOLD)) {
unsigned char new_ctrl = ctrl & ~(CTRL_STOP | CTRL_HOLD);
 
-   printk(KERN_WARNING "RTC: resetting control %02x -> %02x\n",
-  ctrl, new_ctrl);
+   dev_warn(dev, "resetting control %02x -> %02x\n",
+   ctrl, new_ctrl);
 
if ((err = pcf8583_set_ctrl(client, _ctrl)) < 0)
return err;
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 09/11] rtc: rtc-sun4v: use pr_warn() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

No changes since v2:

 drivers/rtc/rtc-sun4v.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-sun4v.c b/drivers/rtc/rtc-sun4v.c
index 5b22610..59b5c2d 100644
--- a/drivers/rtc/rtc-sun4v.c
+++ b/drivers/rtc/rtc-sun4v.c
@@ -3,6 +3,8 @@
  * Copyright (C) 2008 David S. Miller 
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -26,10 +28,10 @@ retry:
udelay(100);
goto retry;
}
-   printk(KERN_WARNING "SUN4V: tod_get() timed out.\n");
+   pr_warn("tod_get() timed out.\n");
return 0;
}
-   printk(KERN_WARNING "SUN4V: tod_get() not supported.\n");
+   pr_warn("tod_get() not supported.\n");
return 0;
 }
 
@@ -53,10 +55,10 @@ retry:
udelay(100);
goto retry;
}
-   printk(KERN_WARNING "SUN4V: tod_set() timed out.\n");
+   pr_warn("tod_set() timed out.\n");
return -EAGAIN;
}
-   printk(KERN_WARNING "SUN4V: tod_set() not supported.\n");
+   pr_warn("tod_set() not supported.\n");
return -EOPNOTSUPP;
 }
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 08/11] rtc: rtc-vr41xx: use dev_info() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

No changes since v2:

 drivers/rtc/rtc-vr41xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-vr41xx.c b/drivers/rtc/rtc-vr41xx.c
index 6c3774c..f91be04 100644
--- a/drivers/rtc/rtc-vr41xx.c
+++ b/drivers/rtc/rtc-vr41xx.c
@@ -352,7 +352,7 @@ static int rtc_probe(struct platform_device *pdev)
disable_irq(aie_irq);
disable_irq(pie_irq);
 
-   printk(KERN_INFO "rtc: Real Time Clock of NEC VR4100 series\n");
+   dev_info(>dev, "Real Time Clock of NEC VR4100 series\n");
 
return 0;
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 07/11] rtc: rtc-rs5c313: use pr_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

Changes since v2:
- Remove redundant prefix

 drivers/rtc/rtc-rs5c313.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-rs5c313.c b/drivers/rtc/rtc-rs5c313.c
index d1aee79..d98ea5b 100644
--- a/drivers/rtc/rtc-rs5c313.c
+++ b/drivers/rtc/rtc-rs5c313.c
@@ -39,6 +39,8 @@
  * 1.13Nobuhiro Iwamatsu: Updata driver.
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -352,8 +354,7 @@ static void rs5c313_check_xstp_bit(void)
tm.tm_year  = 2000 - 1900;
 
rs5c313_rtc_set_time(NULL, );
-   printk(KERN_ERR "RICHO RS5C313: invalid value, resetting to "
-   "1 Jan 2000\n");
+   pr_err("invalid value, resetting to 1 Jan 2000\n");
}
RS5C313_CEDISABLE;
ndelay(700);/* CE:L */
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][CFT] what's in signal.git queue

2013-02-14 Thread Jonas Bonn

On 02/14/13 02:25, Al Viro wrote:

At that point the common stem ends; as far as I'm concerned, this part is
in never-rebase mode by now.  Then comes a bunch of per-architecture branches;
all subject to ACK by maintainers (ones who are not MIA, that is ;-/).  Once
maintainer(s) are OK with a branch, it's in no-rebase mode as well.  Branch
names are of form arch-, same as the last time around.




I tested the arch-openrisc branch and it looks good.

Acked-by: Jonas Bonn 

/Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 06/11] rtc: rtc-at91rm9200: use dev_dbg()/dev_err() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

Changes since v2:
- Remove redundant prefix

 drivers/rtc/rtc-at91rm9200.c |   17 -
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index b6469e2..434ebc3 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -86,7 +86,7 @@ static int at91_rtc_readtime(struct device *dev, struct 
rtc_time *tm)
tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
tm->tm_year = tm->tm_year - 1900;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -100,7 +100,7 @@ static int at91_rtc_settime(struct device *dev, struct 
rtc_time *tm)
 {
unsigned long cr;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -145,7 +145,7 @@ static int at91_rtc_readalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
alrm->enabled = (at91_rtc_read(AT91_RTC_IMR) & AT91_RTC_ALARM)
? 1 : 0;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -183,7 +183,7 @@ static int at91_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
}
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
at91_alarm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour,
tm.tm_min, tm.tm_sec);
 
@@ -192,7 +192,7 @@ static int at91_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
 
 static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 {
-   pr_debug("%s(): cmd=%08x\n", __func__, enabled);
+   dev_dbg(dev, "%s(): cmd=%08x\n", __func__, enabled);
 
if (enabled) {
at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
@@ -240,7 +240,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void *dev_id)
 
rtc_update_irq(rtc, 1, events);
 
-   pr_debug("%s(): num=%ld, events=0x%02lx\n", __func__,
+   dev_dbg(>dev, "%s(): num=%ld, events=0x%02lx\n", __func__,
events >> 8, events & 0x00FF);
 
return IRQ_HANDLED;
@@ -296,8 +296,7 @@ static int __init at91_rtc_probe(struct platform_device 
*pdev)
IRQF_SHARED,
"at91_rtc", pdev);
if (ret) {
-   printk(KERN_ERR "at91_rtc: IRQ %d already in use.\n",
-   irq);
+   dev_err(>dev, "IRQ %d already in use.\n", irq);
return ret;
}
 
@@ -315,7 +314,7 @@ static int __init at91_rtc_probe(struct platform_device 
*pdev)
}
platform_set_drvdata(pdev, rtc);
 
-   printk(KERN_INFO "AT91 Real Time Clock driver.\n");
+   dev_info(>dev, "AT91 Real Time Clock driver.\n");
return 0;
 }
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 05/11] rtc: rtc-rs5c372: use dev_dbg()/dev_warn() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

No changes since v2:

 drivers/rtc/rtc-rs5c372.c |   10 --
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
index 76f565a..581739f 100644
--- a/drivers/rtc/rtc-rs5c372.c
+++ b/drivers/rtc/rtc-rs5c372.c
@@ -311,8 +311,7 @@ static int rs5c_rtc_alarm_irq_enable(struct device *dev, 
unsigned int enabled)
buf &= ~RS5C_CTRL1_AALE;
 
if (i2c_smbus_write_byte_data(client, addr, buf) < 0) {
-   printk(KERN_WARNING "%s: can't update alarm\n",
-   rs5c->rtc->name);
+   dev_warn(dev, "can't update alarm\n");
status = -EIO;
} else
rs5c->regs[RS5C_REG_CTRL1] = buf;
@@ -381,7 +380,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
addr = RS5C_ADDR(RS5C_REG_CTRL1);
buf[0] = rs5c->regs[RS5C_REG_CTRL1] & ~RS5C_CTRL1_AALE;
if (i2c_smbus_write_byte_data(client, addr, buf[0]) < 0) {
-   pr_debug("%s: can't disable alarm\n", rs5c->rtc->name);
+   dev_dbg(dev, "can't disable alarm\n");
return -EIO;
}
rs5c->regs[RS5C_REG_CTRL1] = buf[0];
@@ -395,7 +394,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
for (i = 0; i < sizeof(buf); i++) {
addr = RS5C_ADDR(RS5C_REG_ALARM_A_MIN + i);
if (i2c_smbus_write_byte_data(client, addr, buf[i]) < 0) {
-   pr_debug("%s: can't set alarm time\n", rs5c->rtc->name);
+   dev_dbg(dev, "can't set alarm time\n");
return -EIO;
}
}
@@ -405,8 +404,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
addr = RS5C_ADDR(RS5C_REG_CTRL1);
buf[0] = rs5c->regs[RS5C_REG_CTRL1] | RS5C_CTRL1_AALE;
if (i2c_smbus_write_byte_data(client, addr, buf[0]) < 0)
-   printk(KERN_WARNING "%s: can't enable alarm\n",
-   rs5c->rtc->name);
+   dev_warn(dev, "can't enable alarm\n");
rs5c->regs[RS5C_REG_CTRL1] = buf[0];
}
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 04/11] rtc: rtc-ds2404: use dev_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

No changes since v2:

 drivers/rtc/rtc-ds2404.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ds2404.c b/drivers/rtc/rtc-ds2404.c
index 4539e37..b04fc42 100644
--- a/drivers/rtc/rtc-ds2404.c
+++ b/drivers/rtc/rtc-ds2404.c
@@ -70,7 +70,7 @@ static int ds2404_gpio_map(struct ds2404 *chip, struct 
platform_device *pdev,
for (i = 0; i < ARRAY_SIZE(ds2404_gpio); i++) {
err = gpio_request(ds2404_gpio[i].gpio, ds2404_gpio[i].name);
if (err) {
-   printk(KERN_ERR "error mapping gpio %s: %d\n",
+   dev_err(>dev, "error mapping gpio %s: %d\n",
ds2404_gpio[i].name, err);
goto err_request;
}
@@ -177,7 +177,7 @@ static void ds2404_write_memory(struct device *dev, u16 
offset,
 
for (i = 0; i < length; i++) {
if (out[i] != ds2404_read_byte(dev)) {
-   printk(KERN_ERR "read invalid data\n");
+   dev_err(dev, "read invalid data\n");
return;
}
}
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 03/11] rtc: rtc-efi: use dev_err()/dev_warn()/pr_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warnings as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...
  WARNING: please, no space before tabs

Signed-off-by: Jingoo Han 
---
Changes since v1:
- Repalce pr_warn(), pr_err() with dev_warn(), dev_err()

No changes since v2:

 drivers/rtc/rtc-efi.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index c9f890b..1a0c37c 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -13,6 +13,8 @@
  *
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -47,7 +49,7 @@ compute_wday(efi_time_t *eft)
int ndays = 0;
 
if (eft->year < 1998) {
-   printk(KERN_ERR "efirtc: EFI year < 1998, invalid date\n");
+   pr_err("EFI year < 1998, invalid date\n");
return -1;
}
 
@@ -70,7 +72,7 @@ convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
eft->day= wtime->tm_mday;
eft->hour   = wtime->tm_hour;
eft->minute = wtime->tm_min;
-   eft->second = wtime->tm_sec;
+   eft->second = wtime->tm_sec;
eft->nanosecond = 0;
eft->daylight   = wtime->tm_isdst ? EFI_ISDST : 0;
eft->timezone   = EFI_UNSPECIFIED_TIMEZONE;
@@ -142,7 +144,7 @@ static int efi_set_alarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
 */
status = efi.set_wakeup_time((efi_bool_t)wkalrm->enabled, );
 
-   printk(KERN_WARNING "write status is %d\n", (int)status);
+   dev_warn(dev, "write status is %d\n", (int)status);
 
return status == EFI_SUCCESS ? 0 : -EINVAL;
 }
@@ -157,7 +159,7 @@ static int efi_read_time(struct device *dev, struct 
rtc_time *tm)
 
if (status != EFI_SUCCESS) {
/* should never happen */
-   printk(KERN_ERR "efitime: can't read time\n");
+   dev_err(dev, "can't read time\n");
return -EINVAL;
}
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] sched: The removal of idle_balance()

2013-02-14 Thread Mike Galbraith
On Fri, 2013-02-15 at 01:13 -0500, Steven Rostedt wrote:

> Think about it some more, just because we go idle isn't enough reason to
> pull a runable task over. CPUs go idle all the time, and tasks are woken
> up all the time. There's no reason that we can't just wait for the sched
> tick to decide its time to do a bit of balancing. Sure, it would be nice
> if the idle CPU did the work. But I think that frame of mind was an
> incorrect notion from back in the early 2000s and does not apply to
> today's hardware, or perhaps it doesn't apply to the (relatively) new
> CFS scheduler. If you want aggressive scheduling, make the task rt, and
> it will do aggressive scheduling.

(the throttle is supposed to keep idle_balance() from doing severe
damage, that may want a peek/tweak)

Hackbench spreads itself with FORK/EXEC balancing, how does say a kbuild
do with no idle_balance()?

-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/


Re: pt_regs leak into userspace (was Re: [PATCH v3 20/71] ARC: Signal handling)

2013-02-14 Thread Jonas Bonn
On 11 February 2013 15:07, Al Viro  wrote:

> I'd suggest asking itanic folks; they do *not* put callee-saved stuff into
> sigcontext.  AFAICS, they don't have setcontext() implemented as a syscall
> at all - it's done as sigprocmask() + doing to callee-saved registers what
> longjmp() does.


Just to round off this discussion, after giving it some more thought I
agree that the case where you would need callee-saved registers
restored is probably rather pathological.  Any sane use of
get/set/swapcontext is manageable without this.

So, Vineet, I'm now convinced your approach is sound.  I will probably
amend the OpenRISC arch to behave similarly.  Consider your entire
patch Acked now.

/Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 02/11] rtc: max77686: use dev_info() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

No changes since v2:

 drivers/rtc/rtc-max77686.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 2da0855..abe27c0 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -507,7 +507,7 @@ static int max77686_rtc_probe(struct platform_device *pdev)
struct max77686_rtc_info *info;
int ret, virq;
 
-   printk(KERN_INFO "%s\n", __func__);
+   dev_info(>dev, "%s\n", __func__);
 
info = kzalloc(sizeof(struct max77686_rtc_info), GFP_KERNEL);
if (!info)
@@ -546,7 +546,7 @@ static int max77686_rtc_probe(struct platform_device *pdev)
_rtc_ops, THIS_MODULE);
 
if (IS_ERR(info->rtc_dev)) {
-   printk(KERN_INFO "%s: fail\n", __func__);
+   dev_info(>dev, "%s: fail\n", __func__);
 
ret = PTR_ERR(info->rtc_dev);
dev_err(>dev, "Failed to register RTC device: %d\n", ret);
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V3 01/11] rtc: use dev_warn()/dev_dbg()/pr_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
Changes since v1:
- Repalce pr_warn(), pr_debug() with dev_warn(), dev_dbg()

No Changes since v2:

 drivers/rtc/class.c   |4 +++-
 drivers/rtc/rtc-dev.c |   11 ++-
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 26388f1..9b742d3 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -11,6 +11,8 @@
  * published by the Free Software Foundation.
 */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -261,7 +263,7 @@ static int __init rtc_init(void)
 {
rtc_class = class_create(THIS_MODULE, "rtc");
if (IS_ERR(rtc_class)) {
-   printk(KERN_ERR "%s: couldn't create class\n", __FILE__);
+   pr_err("couldn't create class\n");
return PTR_ERR(rtc_class);
}
rtc_class->suspend = rtc_suspend;
diff --git a/drivers/rtc/rtc-dev.c b/drivers/rtc/rtc-dev.c
index 9a86b4b..d049393 100644
--- a/drivers/rtc/rtc-dev.c
+++ b/drivers/rtc/rtc-dev.c
@@ -11,6 +11,8 @@
  * published by the Free Software Foundation.
 */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -462,7 +464,7 @@ void rtc_dev_prepare(struct rtc_device *rtc)
return;
 
if (rtc->id >= RTC_DEV_MAX) {
-   pr_debug("%s: too many RTC devices\n", rtc->name);
+   dev_dbg(>dev, "%s: too many RTC devices\n", rtc->name);
return;
}
 
@@ -480,10 +482,10 @@ void rtc_dev_prepare(struct rtc_device *rtc)
 void rtc_dev_add_device(struct rtc_device *rtc)
 {
if (cdev_add(>char_dev, rtc->dev.devt, 1))
-   printk(KERN_WARNING "%s: failed to add char device %d:%d\n",
+   dev_warn(>dev, "%s: failed to add char device %d:%d\n",
rtc->name, MAJOR(rtc_devt), rtc->id);
else
-   pr_debug("%s: dev (%d:%d)\n", rtc->name,
+   dev_dbg(>dev, "%s: dev (%d:%d)\n", rtc->name,
MAJOR(rtc_devt), rtc->id);
 }
 
@@ -499,8 +501,7 @@ void __init rtc_dev_init(void)
 
err = alloc_chrdev_region(_devt, 0, RTC_DEV_MAX, "rtc");
if (err < 0)
-   printk(KERN_ERR "%s: failed to allocate char dev region\n",
-   __FILE__);
+   pr_err("failed to allocate char dev region\n");
 }
 
 void __exit rtc_dev_exit(void)
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] tcp: sysctl to disable TCP simultaneous connect

2013-02-14 Thread Eric W. Biederman
Kees Cook  writes:

> On Thu, Feb 14, 2013 at 9:30 PM, Eric W. Biederman
>  wrote:
>> Kees Cook  writes:
>>
>>> The patch would not break it -- it defaults the sysctl to staying enabled.
>>>
>>> If you mean the documentation should be updated, sure, that's easy to do.
>>>
>>> David: I know you aren't a fan of this patch, but I'd like to try to
>>> convince you. :) This leaves the feature enabled and add a toggle for
>>> systems (like Chrome OS) that don't want to risk this DoS at all.
>>> There are so very many other toggle, I don't see why this one would be
>>> a problem to add.
>>
>> Chrome OS has no plans to implement webrtc?  Last I had read that
>> support had been added to the release versions of Chrome, and was in the
>> development builds of firefox.  I really don't belive that there are
>> many systems that don't intend to run a web browser.
>
> I haven't looked at the internals of webrtc. Are you implying some
> feature in it relies on the TCP simultaneous connect?

I am saying that yes.

webrtc is built on ICE (interactivity connectivity establishment).  ICE
support for TCP (RFC6544) uses TCP simultaneous connect.  webrtc
supports tcp connections.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATHC] 3.6 spinlock fix

2013-02-14 Thread Tim Sander
Hi
> On Thu, Feb 14, 2013 at 5:35 PM, Thomas Gleixner  wrote:
> > On Thu, 14 Feb 2013, Tim Sander wrote:
> >> > That's true, but w/o seing the OOM output I can't tell what's
> >> > exhausting the memory.
> >> 
> >> When fuzzing the serial port one probably should switch of sysreq. It
> >> seems
> >> as if there is a break send somehow and then it selects the OOM option.
> >> So when switching of MAGIC_SYSRQ the OOMs are gone. So its a non issue.
> > 
> > Amazing that you get the break+oom combo out of that fuzzer!
That fuzzer is running at 57600Hz while the serial port of the fuzzed device is
running twice that rate. The break condition seems to be easy hit by the fuzzer
 i've sent in a previous mail. 
> Doing a basic "git whatchanged" and searching for "trinity" is rather
> impressive, regardless of the kernel version and/or where "rogue states"
> may currently be at with their "program"   Kudos to davej for that.
Mh, but thats not trinity! Havn't tried that but well fuzzing at a different 
serial rate than the receiver might be a good idea even if it sounds pretty 
stupid.

Attached is the patch for the 3.6.9-rt kernel (but i think this should also 
apply 
to the "normal" 3.6 i guess).  But as Greg already took care of this patch i 
guess 
that only for convinience. Also it seems as if the patch sent to Greg is 
missing the
#include ?

Best regards
Tim

tglx: fix imx.c spinlock

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e309e8b..39820ea 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1213,8 +1214,12 @@ imx_console_write(struct console *co, const char *s, 
unsigned int count)
struct imx_port_ucrs old_ucr;
unsigned int ucr1;
unsigned long flags;
+   int locked = 1;
 
-   spin_lock_irqsave(>port.lock, flags);
+   if (sport->port.sysrq || oops_in_progress || in_kdb_printk())
+   locked = spin_trylock_irqsave(>port.lock, flags);
+   else
+   spin_lock_irqsave(>port.lock, flags);
 
/*
 *  First, save UCR1/2/3 and then disable interrupts
@@ -1241,7 +1246,8 @@ imx_console_write(struct console *co, const char *s, 
unsigned int count)
 
imx_port_ucrs_restore(>port, _ucr);
 
-   spin_unlock_irqrestore(>port.lock, flags);
+   if (locked)
+   spin_unlock_irqrestore(>port.lock, flags);
 }
 
 /*

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] kernel: allow reboots from user_ns

2013-02-14 Thread Glauber Costa
On 02/14/2013 06:58 PM, Eric W. Biederman wrote:
>> I didn't see that, and using Linus' master my stop container scripts
>> > stopped working after I started using Eric's userns...
> The patch has been sitting in my for-next branch for quite a while
> just waiting for the merge window.
> 
> Eric
Fine by me.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7] iio: adc: add exynos adc driver under iio framwork

2013-02-14 Thread Naveen Krishna Chatradhi
This patch adds New driver to support:
1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
   and future SoCs from Samsung
2. Add ADC driver under iio/adc framework
3. Also adds the Documentation for device tree bindings

Signed-off-by: Naveen Krishna Chatradhi 
---
Changes since v1:

1. Fixed comments from Lars
2. Added support for ADC on EXYNOS5410

Changes since v2:

1. Changed the instance name for (struct iio_dev *) to indio_dev
2. Changed devm_request_irq to request_irq

Few doubts regarding the mappings and child device handling.
Kindly, suggest me better methods.

Changes since v3:

1. Added clk_prepare_disable and regulator_disable calls in _remove()
2. Moved init_completion before irq_request
3. Added NULL pointer check for devm_request_and_ioremap() return value.
4. Use number of channels as per the ADC version
5. Change the define ADC_V1_CHANNEL to ADC_CHANNEL
6. Update the Documentation to include EXYNOS5410 compatible

Changes since v4:

1. if devm_request_and_ioremap() failes, free iio_device before returning

Changes since v5:

1. Fixed comments from Olof (ADC hardware version handling)
2. Rebased on top of comming OF framework for IIO by "Guenter Roeck".

Changes since v6:

1. Addressed comments from Lars-Peter Clausen

 .../bindings/arm/samsung/exynos5-adc.txt   |   42 ++
 drivers/iio/adc/Kconfig|7 +
 drivers/iio/adc/Makefile   |1 +
 drivers/iio/adc/exynos_adc.c   |  438 
 4 files changed, 488 insertions(+)
 .../devicetree/bindings/arm/samsung/exynos-adc.txt |   52 +++
 drivers/iio/adc/Kconfig|7 +
 drivers/iio/adc/Makefile   |1 +
 drivers/iio/adc/exynos_adc.c   |  440 
 4 files changed, 500 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
 create mode 100644 drivers/iio/adc/exynos_adc.c

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
new file mode 100644
index 000..f686378
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -0,0 +1,52 @@
+Samsung Exynos Analog to Digital Converter bindings
+
+This devicetree binding are for the new adc driver written fori
+Exynos4 and upward SoCs from Samsung.
+
+New driver handles the following
+1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
+   and future SoCs from Samsung
+2. Add ADC driver under iio/adc framework
+3. Also adds the Documentation for device tree bindings
+
+Required properties:
+- compatible:  Must be "samsung,exynos-adc-v1"
+   for exynos4412/5250 controllers.
+   Must be "samsung,exynos-adc-v2" for
+   future controllers.
+- reg: Contains ADC register address range (base address and
+   length).
+- interrupts:  Contains the interrupt information for the timer. The
+   format is being dependent on which interrupt controller
+   the Samsung device uses.
+- #io-channel-cells = <1>; As ADC has multiple outputs
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc: adc@12D1 {
+   compatible = "samsung,exynos-adc-v1";
+   reg = <0x12D1 0x100>;
+   interrupts = <0 106 0>;
+   #io-channel-cells = <1>;
+   io-channel-ranges;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D1 {
+
+   /* NTC thermistor is a hwmon device */
+   ncp15wb473@0 {
+   compatible = "ntc,ncp15wb473";
+   pullup-uV = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = < 4>;
+   };
+};
+
+Note: Does not apply to ADC driver under arch/arm/plat-samsung/
+Note: The child node can be added under the adc node or seperately.
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index e372257..04311f8 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -91,6 +91,13 @@ config AT91_ADC
help
  Say yes here to build support for Atmel AT91 ADC.
 
+config EXYNOS_ADC
+   bool "Exynos ADC driver support"
+   help
+ Core support for the ADC block found in the Samsung EXYNOS series
+ of SoCs for drivers such as the touchscreen and hwmon to use to share
+ this resource.
+
 config LP8788_ADC
bool "LP8788 ADC driver"
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 2d5f100..fabac2c 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_AD7791) += ad7791.o
 obj-$(CONFIG_AD7793) += ad7793.o
 obj-$(CONFIG_AD7887) += ad7887.o
 obj-$(CONFIG_AT91_ADC) += at91_adc.o

linux-next: manual merge of the akpm tree with the net-next tree

2013-02-14 Thread Stephen Rothwell
Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
net/bridge/br_fdb.c between commit 2ba071ecb6d4 ("bridge: Add vlan to
unicast fdb entries") from the net-next tree and commit "hlist: drop the
node parameter from iterators" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc net/bridge/br_fdb.c
index 8117900,4fb0461..000
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@@ -263,16 -231,12 +263,15 @@@ void br_fdb_delete_by_port(struct net_b
  
  /* No locking or refcounting, assumes caller has rcu_read_lock */
  struct net_bridge_fdb_entry *__br_fdb_get(struct net_bridge *br,
 -const unsigned char *addr)
 +const unsigned char *addr,
 +__u16 vid)
  {
-   struct hlist_node *h;
struct net_bridge_fdb_entry *fdb;
  
-   hlist_for_each_entry_rcu(fdb, h,
 -  hlist_for_each_entry_rcu(fdb, >hash[br_mac_hash(addr)], hlist) {
 -  if (ether_addr_equal(fdb->addr.addr, addr)) {
++  hlist_for_each_entry_rcu(fdb,
 +  >hash[br_mac_hash(addr, vid)], hlist) {
 +  if (ether_addr_equal(fdb->addr.addr, addr) &&
 +  fdb->vlan_id == vid) {
if (unlikely(has_expired(br, fdb)))
break;
return fdb;
@@@ -360,30 -323,24 +358,28 @@@ int br_fdb_fillbuf(struct net_bridge *b
  }
  
  static struct net_bridge_fdb_entry *fdb_find(struct hlist_head *head,
 -   const unsigned char *addr)
 +   const unsigned char *addr,
 +   __u16 vid)
  {
-   struct hlist_node *h;
struct net_bridge_fdb_entry *fdb;
  
-   hlist_for_each_entry(fdb, h, head, hlist) {
+   hlist_for_each_entry(fdb, head, hlist) {
 -  if (ether_addr_equal(fdb->addr.addr, addr))
 +  if (ether_addr_equal(fdb->addr.addr, addr) &&
 +  fdb->vlan_id == vid)
return fdb;
}
return NULL;
  }
  
  static struct net_bridge_fdb_entry *fdb_find_rcu(struct hlist_head *head,
 -   const unsigned char *addr)
 +   const unsigned char *addr,
 +   __u16 vid)
  {
-   struct hlist_node *h;
struct net_bridge_fdb_entry *fdb;
  
-   hlist_for_each_entry_rcu(fdb, h, head, hlist) {
+   hlist_for_each_entry_rcu(fdb, head, hlist) {
 -  if (ether_addr_equal(fdb->addr.addr, addr))
 +  if (ether_addr_equal(fdb->addr.addr, addr) &&
 +  fdb->vlan_id == vid)
return fdb;
}
return NULL;


pgp2_6YZ2EFhd.pgp
Description: PGP signature


Re: [PATCH 7/9] remoteproc: omap: depend on OMAP_MBOX_FWK

2013-02-14 Thread Ohad Ben-Cohen
On Fri, Feb 15, 2013 at 12:55 AM, Tony Lindgren  wrote:
> * Arnd Bergmann  [130214 14:51]:
>> Patch a62a6e98 "ARM: OMAP2+: Disable code that currently does not work
>> with multiplaform" makes the OMAP_MBOX_FWK option depend on !MULTIPLATFORM,
>> which means we cannot simply select that symbol from OMAP_REMOTEPROC.
>>
>> Turning the 'select' into 'depends on' ensures that all dependencies
>> are correct until OMAP_MBOX_FWK loses its dependency.
>>
>> Without this patch, building allmodconfig results in:
>>
>> drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No 
>> such file or directory
>>
>> Signed-off-by: Arnd Bergmann 
>
> Acked-by: Tony Lindgren 

Acked-by: Ohad Ben-Cohen 

Feel free to take this via your tree - thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [tip:core/locking] x86/smp: Move waiting on contended ticket lock out of line

2013-02-14 Thread Benjamin Herrenschmidt
On Wed, 2013-02-13 at 10:30 -0800, Linus Torvalds wrote:
> On Wed, Feb 13, 2013 at 8:20 AM, Linus Torvalds
>  wrote:
> >
> > Adding an external function call is *horrible*, and you might almost
> > as well just uninline the spinlock entirely if you do this. It means
> > that all the small callers now have their registers trashed, whether
> > the unlikely function call is taken or not, and now leaf functions
> > aren't leaves any more.
> 
> Btw, we've had things like this before, and I wonder if we could
> perhaps introduce the notion of a "light-weight call" for fastpath
> code that calls unlikely slow-path code..
> 
> In particular, see the out-of-line code used by the rwlocks etc (see
> "arch_read_lock()" for an example in arch/x86/include/asm/spinlock.h
> and arch/x86/lib/rwlock.S), where we end up calling things from inline
> asm, with one big reason being exactly the fact that a "normal" C call
> has such horribly detrimental effects on the caller.

This would be nice. I've been wanting to do something like that for a
while in fact... On archs like powerpc, we lose 11 GPRs on a function
call, that ends up being a lot of stupid stack spills for cases that are
often corner cases (error cases etc... in inlines).

> Sadly, gcc doesn't seem to allow specifying which registers are
> clobbered any easy way, which means that both the caller and the
> callee *both* tend to need to have some asm interface. So we bothered
> to do this for __read_lock_failed, but we have *not* bothered to do
> the same for the otherwise very similar __mutex_fastpath_lock() case,
> for example.
>
> So for rwlocks, we actually get very nice code generation with small
> leaf functions not necessarily needing stack frames, but for mutexes
> we mark a lot of registers "unnecessarily" clobbered in the caller,
> exactly because we do *not* do that asm interface for the callee. So
> we have to clobber all the standard callee-clobbered registers, which
> is really sad, and callers almost always need a stack frame, because
> if they have any data live at all across the mutex, they have to save
> it in some register that is callee-saved - which basically means that
> the function has to have that stack frame in order to save its *own*
> callee-saved registers.
> 
> So it means that we penalize the fastpath because the slow-path can't
> be bothered to do the extra register saving, unless we go to the
> lengths we went to for the rwlocks, and build a wrapper in asm to save
> the extra registers in the cold path.
> 
> Maybe we could introduce some helpers to create these kinds of asm
> wrappers to do this? Something that would allow us to say: "this
> function only clobbers a minimal set of registers and you can call it
> from asm and only mark %rax/rcx/rdx clobbered" and that allows leaf
> functions to look like leaf functions for the fastpath?

We could so something like:

define_fastcall(func [.. figure out how to deal with args ... ])

Which spits out both a trampoline for saving the nasty stuff and calling
the real func() and a call_func() inline asm for the call site.

At least on archs with register-passing conventions, especially if we
make mandatory to stick to register args only and forbid stack spills
(ie, only a handful of args), it's fairly easy to do.

For stack based archs, it gets nastier as you have to dig out the args,
save stuff, and pile them again.

But since we also don't want to lose strong typing, we probably want to
express the args in that macro, maybe like we do for the syscall
defines. A bit ugly, but that would allow to have a strongly typed
call_func() *and* allow the trampoline to know what to do about the args
for stack based calling conventions.

About to go & travel so I don't have time to actually write something,
at least not for a couple of weeks though...

Ben.

> Hmm? That would make my dislike of uninlining the slow case largely go
> away. I still think that back-off tends to be a mistake (and is often
> horrible for virtualization etc), but as long as the fastpath stays
> close to optimal, I don't care *too* much.
> 
>  Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/11] rtc: rtc-rs5c313: use pr_err() instead of printk()

2013-02-14 Thread Jingoo Han
On Friday, February 15, 2013 3:50 PM, Joe Perches wrote:
> On Fri, 2013-02-15 at 15:46 +0900, Jingoo Han wrote:
> > Fixed the checkpatch warning as below:
> []
> > diff --git a/drivers/rtc/rtc-rs5c313.c b/drivers/rtc/rtc-rs5c313.c
> []
> > @@ -39,6 +39,8 @@
> >   * 1.13Nobuhiro Iwamatsu: Updata driver.
> >   */
> >
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > +
> >  #include 
> >  #include 
> >  #include 
> > @@ -352,8 +354,7 @@ static void rs5c313_check_xstp_bit(void)
> > tm.tm_year  = 2000 - 1900;
> >
> > rs5c313_rtc_set_time(NULL, );
> > -   printk(KERN_ERR "RICHO RS5C313: invalid value, resetting to "
> > -   "1 Jan 2000\n");
> > +   pr_err("RICHO RS5C313: invalid value, resetting to 1 Jan 
> > 2000\n");
> 
> You could remove the "RICH0 RS5C313: "prefix,
> pr_fmt adds it (more or less).

OK, I will remove it.
Thank you.

Best regards,
Jingoo Han


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


linux-next: manual merge of the akpm tree with the workqueues tree

2013-02-14 Thread Stephen Rothwell
Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
kernel/workqueue.c between commit 8d03ecfe4718 ("workqueue: reimplement
is_chained_work() using current_wq_worker()") from the workqueues tree
and commit "hlist: drop the node parameter from iterators" from the akpm
tree.

I fixed it up (the former removes the code changed by the latter, so I
did that) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpn0w_mbMfeV.pgp
Description: PGP signature


Re: [PATCH V2 07/11] rtc: rtc-rs5c313: use pr_err() instead of printk()

2013-02-14 Thread Joe Perches
On Fri, 2013-02-15 at 15:46 +0900, Jingoo Han wrote:
> Fixed the checkpatch warning as below:
[]
> diff --git a/drivers/rtc/rtc-rs5c313.c b/drivers/rtc/rtc-rs5c313.c
[]
> @@ -39,6 +39,8 @@
>   *   1.13Nobuhiro Iwamatsu: Updata driver.
>   */
>  
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
>  #include 
>  #include 
>  #include 
> @@ -352,8 +354,7 @@ static void rs5c313_check_xstp_bit(void)
>   tm.tm_year  = 2000 - 1900;
>  
>   rs5c313_rtc_set_time(NULL, );
> - printk(KERN_ERR "RICHO RS5C313: invalid value, resetting to "
> - "1 Jan 2000\n");
> + pr_err("RICHO RS5C313: invalid value, resetting to 1 Jan 
> 2000\n");

You could remove the "RICH0 RS5C313: "prefix,
pr_fmt adds it (more or less).


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/11] rtc: rtc-cmos: use dev_warn()/dev_dbg() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-cmos.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 9deb9e4..af97c94 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -706,7 +706,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, 
int rtc_irq)
rtc_cmos_int_handler = hpet_rtc_interrupt;
err = hpet_register_irq_handler(cmos_interrupt);
if (err != 0) {
-   printk(KERN_WARNING "hpet_register_irq_handler "
+   dev_warn(dev, "hpet_register_irq_handler "
" failed in rtc_init().");
goto cleanup1;
}
@@ -731,8 +731,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, 
int rtc_irq)
goto cleanup2;
}
 
-   pr_info("%s: %s%s, %zd bytes nvram%s\n",
-   dev_name(_rtc.rtc->dev),
+   dev_info(dev, "%s%s, %zd bytes nvram%s\n",
!is_valid_irq(rtc_irq) ? "no alarms" :
cmos_rtc.mon_alrm ? "alarms up to one year" :
cmos_rtc.day_alrm ? "alarms up to one month" :
@@ -820,8 +819,7 @@ static int cmos_suspend(struct device *dev)
enable_irq_wake(cmos->irq);
}
 
-   pr_debug("%s: suspend%s, ctrl %02x\n",
-   dev_name(_rtc.rtc->dev),
+   dev_dbg(dev, "suspend%s, ctrl %02x\n",
(tmp & RTC_AIE) ? ", alarm may wake" : "",
tmp);
 
@@ -876,9 +874,7 @@ static int cmos_resume(struct device *dev)
spin_unlock_irq(_lock);
}
 
-   pr_debug("%s: resume, ctrl %02x\n",
-   dev_name(_rtc.rtc->dev),
-   tmp);
+   dev_dbg(dev, "resume, ctrl %02x\n", tmp);
 
return 0;
 }
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 10/11] rtc: rtc-pcf8583: use dev_warn() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-pcf8583.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-pcf8583.c b/drivers/rtc/rtc-pcf8583.c
index 3415b8f..aa9bf2b 100644
--- a/drivers/rtc/rtc-pcf8583.c
+++ b/drivers/rtc/rtc-pcf8583.c
@@ -185,7 +185,7 @@ static int pcf8583_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
if (ctrl & (CTRL_STOP | CTRL_HOLD)) {
unsigned char new_ctrl = ctrl & ~(CTRL_STOP | CTRL_HOLD);
 
-   printk(KERN_WARNING "RTC: resetting control %02x -> %02x\n",
+   dev_warn(dev, "RTC: resetting control %02x -> %02x\n",
   ctrl, new_ctrl);
 
if ((err = pcf8583_set_ctrl(client, _ctrl)) < 0)
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 09/11] rtc: rtc-sun4v: use pr_warn() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-sun4v.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-sun4v.c b/drivers/rtc/rtc-sun4v.c
index 5b22610..59b5c2d 100644
--- a/drivers/rtc/rtc-sun4v.c
+++ b/drivers/rtc/rtc-sun4v.c
@@ -3,6 +3,8 @@
  * Copyright (C) 2008 David S. Miller 
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -26,10 +28,10 @@ retry:
udelay(100);
goto retry;
}
-   printk(KERN_WARNING "SUN4V: tod_get() timed out.\n");
+   pr_warn("tod_get() timed out.\n");
return 0;
}
-   printk(KERN_WARNING "SUN4V: tod_get() not supported.\n");
+   pr_warn("tod_get() not supported.\n");
return 0;
 }
 
@@ -53,10 +55,10 @@ retry:
udelay(100);
goto retry;
}
-   printk(KERN_WARNING "SUN4V: tod_set() timed out.\n");
+   pr_warn("tod_set() timed out.\n");
return -EAGAIN;
}
-   printk(KERN_WARNING "SUN4V: tod_set() not supported.\n");
+   pr_warn("tod_set() not supported.\n");
return -EOPNOTSUPP;
 }
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 08/11] rtc: rtc-vr41xx: use dev_info() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-vr41xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-vr41xx.c b/drivers/rtc/rtc-vr41xx.c
index 6c3774c..f91be04 100644
--- a/drivers/rtc/rtc-vr41xx.c
+++ b/drivers/rtc/rtc-vr41xx.c
@@ -352,7 +352,7 @@ static int rtc_probe(struct platform_device *pdev)
disable_irq(aie_irq);
disable_irq(pie_irq);
 
-   printk(KERN_INFO "rtc: Real Time Clock of NEC VR4100 series\n");
+   dev_info(>dev, "Real Time Clock of NEC VR4100 series\n");
 
return 0;
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 07/11] rtc: rtc-rs5c313: use pr_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-rs5c313.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-rs5c313.c b/drivers/rtc/rtc-rs5c313.c
index d1aee79..8ca55a6 100644
--- a/drivers/rtc/rtc-rs5c313.c
+++ b/drivers/rtc/rtc-rs5c313.c
@@ -39,6 +39,8 @@
  * 1.13Nobuhiro Iwamatsu: Updata driver.
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -352,8 +354,7 @@ static void rs5c313_check_xstp_bit(void)
tm.tm_year  = 2000 - 1900;
 
rs5c313_rtc_set_time(NULL, );
-   printk(KERN_ERR "RICHO RS5C313: invalid value, resetting to "
-   "1 Jan 2000\n");
+   pr_err("RICHO RS5C313: invalid value, resetting to 1 Jan 
2000\n");
}
RS5C313_CEDISABLE;
ndelay(700);/* CE:L */
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 06/11] rtc: rtc-at91rm9200: use dev_dbg()/dev_err() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-at91rm9200.c |   17 -
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index b6469e2..4a2e451 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -86,7 +86,7 @@ static int at91_rtc_readtime(struct device *dev, struct 
rtc_time *tm)
tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
tm->tm_year = tm->tm_year - 1900;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -100,7 +100,7 @@ static int at91_rtc_settime(struct device *dev, struct 
rtc_time *tm)
 {
unsigned long cr;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -145,7 +145,7 @@ static int at91_rtc_readalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
alrm->enabled = (at91_rtc_read(AT91_RTC_IMR) & AT91_RTC_ALARM)
? 1 : 0;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -183,7 +183,7 @@ static int at91_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
}
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
at91_alarm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour,
tm.tm_min, tm.tm_sec);
 
@@ -192,7 +192,7 @@ static int at91_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
 
 static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 {
-   pr_debug("%s(): cmd=%08x\n", __func__, enabled);
+   dev_dbg(dev, "%s(): cmd=%08x\n", __func__, enabled);
 
if (enabled) {
at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
@@ -240,7 +240,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void *dev_id)
 
rtc_update_irq(rtc, 1, events);
 
-   pr_debug("%s(): num=%ld, events=0x%02lx\n", __func__,
+   dev_dbg(>dev, "%s(): num=%ld, events=0x%02lx\n", __func__,
events >> 8, events & 0x00FF);
 
return IRQ_HANDLED;
@@ -296,8 +296,7 @@ static int __init at91_rtc_probe(struct platform_device 
*pdev)
IRQF_SHARED,
"at91_rtc", pdev);
if (ret) {
-   printk(KERN_ERR "at91_rtc: IRQ %d already in use.\n",
-   irq);
+   dev_err(>dev, "at91_rtc: IRQ %d already in use.\n", irq);
return ret;
}
 
@@ -315,7 +314,7 @@ static int __init at91_rtc_probe(struct platform_device 
*pdev)
}
platform_set_drvdata(pdev, rtc);
 
-   printk(KERN_INFO "AT91 Real Time Clock driver.\n");
+   dev_info(>dev, "AT91 Real Time Clock driver.\n");
return 0;
 }
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 05/11] rtc: rtc-rs5c372: use dev_dbg()/dev_warn() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-rs5c372.c |   10 --
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
index 76f565a..581739f 100644
--- a/drivers/rtc/rtc-rs5c372.c
+++ b/drivers/rtc/rtc-rs5c372.c
@@ -311,8 +311,7 @@ static int rs5c_rtc_alarm_irq_enable(struct device *dev, 
unsigned int enabled)
buf &= ~RS5C_CTRL1_AALE;
 
if (i2c_smbus_write_byte_data(client, addr, buf) < 0) {
-   printk(KERN_WARNING "%s: can't update alarm\n",
-   rs5c->rtc->name);
+   dev_warn(dev, "can't update alarm\n");
status = -EIO;
} else
rs5c->regs[RS5C_REG_CTRL1] = buf;
@@ -381,7 +380,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
addr = RS5C_ADDR(RS5C_REG_CTRL1);
buf[0] = rs5c->regs[RS5C_REG_CTRL1] & ~RS5C_CTRL1_AALE;
if (i2c_smbus_write_byte_data(client, addr, buf[0]) < 0) {
-   pr_debug("%s: can't disable alarm\n", rs5c->rtc->name);
+   dev_dbg(dev, "can't disable alarm\n");
return -EIO;
}
rs5c->regs[RS5C_REG_CTRL1] = buf[0];
@@ -395,7 +394,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
for (i = 0; i < sizeof(buf); i++) {
addr = RS5C_ADDR(RS5C_REG_ALARM_A_MIN + i);
if (i2c_smbus_write_byte_data(client, addr, buf[i]) < 0) {
-   pr_debug("%s: can't set alarm time\n", rs5c->rtc->name);
+   dev_dbg(dev, "can't set alarm time\n");
return -EIO;
}
}
@@ -405,8 +404,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
addr = RS5C_ADDR(RS5C_REG_CTRL1);
buf[0] = rs5c->regs[RS5C_REG_CTRL1] | RS5C_CTRL1_AALE;
if (i2c_smbus_write_byte_data(client, addr, buf[0]) < 0)
-   printk(KERN_WARNING "%s: can't enable alarm\n",
-   rs5c->rtc->name);
+   dev_warn(dev, "can't enable alarm\n");
rs5c->regs[RS5C_REG_CTRL1] = buf[0];
}
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 04/11] rtc: rtc-ds2404: use dev_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-ds2404.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ds2404.c b/drivers/rtc/rtc-ds2404.c
index 4539e37..b04fc42 100644
--- a/drivers/rtc/rtc-ds2404.c
+++ b/drivers/rtc/rtc-ds2404.c
@@ -70,7 +70,7 @@ static int ds2404_gpio_map(struct ds2404 *chip, struct 
platform_device *pdev,
for (i = 0; i < ARRAY_SIZE(ds2404_gpio); i++) {
err = gpio_request(ds2404_gpio[i].gpio, ds2404_gpio[i].name);
if (err) {
-   printk(KERN_ERR "error mapping gpio %s: %d\n",
+   dev_err(>dev, "error mapping gpio %s: %d\n",
ds2404_gpio[i].name, err);
goto err_request;
}
@@ -177,7 +177,7 @@ static void ds2404_write_memory(struct device *dev, u16 
offset,
 
for (i = 0; i < length; i++) {
if (out[i] != ds2404_read_byte(dev)) {
-   printk(KERN_ERR "read invalid data\n");
+   dev_err(dev, "read invalid data\n");
return;
}
}
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 03/11] rtc: rtc-efi: use dev_err()/dev_warn()/pr_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warnings as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...
  WARNING: please, no space before tabs

Signed-off-by: Jingoo Han 
---
Changes since v1:
- Repalce pr_warn(), pr_err() with dev_warn(), dev_err()

 drivers/rtc/rtc-efi.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index c9f890b..1a0c37c 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -13,6 +13,8 @@
  *
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -47,7 +49,7 @@ compute_wday(efi_time_t *eft)
int ndays = 0;
 
if (eft->year < 1998) {
-   printk(KERN_ERR "efirtc: EFI year < 1998, invalid date\n");
+   pr_err("EFI year < 1998, invalid date\n");
return -1;
}
 
@@ -70,7 +72,7 @@ convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
eft->day= wtime->tm_mday;
eft->hour   = wtime->tm_hour;
eft->minute = wtime->tm_min;
-   eft->second = wtime->tm_sec;
+   eft->second = wtime->tm_sec;
eft->nanosecond = 0;
eft->daylight   = wtime->tm_isdst ? EFI_ISDST : 0;
eft->timezone   = EFI_UNSPECIFIED_TIMEZONE;
@@ -142,7 +144,7 @@ static int efi_set_alarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
 */
status = efi.set_wakeup_time((efi_bool_t)wkalrm->enabled, );
 
-   printk(KERN_WARNING "write status is %d\n", (int)status);
+   dev_warn(dev, "write status is %d\n", (int)status);
 
return status == EFI_SUCCESS ? 0 : -EINVAL;
 }
@@ -157,7 +159,7 @@ static int efi_read_time(struct device *dev, struct 
rtc_time *tm)
 
if (status != EFI_SUCCESS) {
/* should never happen */
-   printk(KERN_ERR "efitime: can't read time\n");
+   dev_err(dev, "can't read time\n");
return -EINVAL;
}
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 02/11] rtc: max77686: use dev_info() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/rtc/rtc-max77686.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 2da0855..abe27c0 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -507,7 +507,7 @@ static int max77686_rtc_probe(struct platform_device *pdev)
struct max77686_rtc_info *info;
int ret, virq;
 
-   printk(KERN_INFO "%s\n", __func__);
+   dev_info(>dev, "%s\n", __func__);
 
info = kzalloc(sizeof(struct max77686_rtc_info), GFP_KERNEL);
if (!info)
@@ -546,7 +546,7 @@ static int max77686_rtc_probe(struct platform_device *pdev)
_rtc_ops, THIS_MODULE);
 
if (IS_ERR(info->rtc_dev)) {
-   printk(KERN_INFO "%s: fail\n", __func__);
+   dev_info(>dev, "%s: fail\n", __func__);
 
ret = PTR_ERR(info->rtc_dev);
dev_err(>dev, "Failed to register RTC device: %d\n", ret);
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2 01/11] rtc: use dev_warn()/dev_dbg()/pr_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
Changes since v1:
- Repalce pr_warn(), pr_debug() with dev_warn(), dev_dbg()

 drivers/rtc/class.c   |4 +++-
 drivers/rtc/rtc-dev.c |   11 ++-
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 26388f1..9b742d3 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -11,6 +11,8 @@
  * published by the Free Software Foundation.
 */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -261,7 +263,7 @@ static int __init rtc_init(void)
 {
rtc_class = class_create(THIS_MODULE, "rtc");
if (IS_ERR(rtc_class)) {
-   printk(KERN_ERR "%s: couldn't create class\n", __FILE__);
+   pr_err("couldn't create class\n");
return PTR_ERR(rtc_class);
}
rtc_class->suspend = rtc_suspend;
diff --git a/drivers/rtc/rtc-dev.c b/drivers/rtc/rtc-dev.c
index 9a86b4b..d049393 100644
--- a/drivers/rtc/rtc-dev.c
+++ b/drivers/rtc/rtc-dev.c
@@ -11,6 +11,8 @@
  * published by the Free Software Foundation.
 */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -462,7 +464,7 @@ void rtc_dev_prepare(struct rtc_device *rtc)
return;
 
if (rtc->id >= RTC_DEV_MAX) {
-   pr_debug("%s: too many RTC devices\n", rtc->name);
+   dev_dbg(>dev, "%s: too many RTC devices\n", rtc->name);
return;
}
 
@@ -480,10 +482,10 @@ void rtc_dev_prepare(struct rtc_device *rtc)
 void rtc_dev_add_device(struct rtc_device *rtc)
 {
if (cdev_add(>char_dev, rtc->dev.devt, 1))
-   printk(KERN_WARNING "%s: failed to add char device %d:%d\n",
+   dev_warn(>dev, "%s: failed to add char device %d:%d\n",
rtc->name, MAJOR(rtc_devt), rtc->id);
else
-   pr_debug("%s: dev (%d:%d)\n", rtc->name,
+   dev_dbg(>dev, "%s: dev (%d:%d)\n", rtc->name,
MAJOR(rtc_devt), rtc->id);
 }
 
@@ -499,8 +501,7 @@ void __init rtc_dev_init(void)
 
err = alloc_chrdev_region(_devt, 0, RTC_DEV_MAX, "rtc");
if (err < 0)
-   printk(KERN_ERR "%s: failed to allocate char dev region\n",
-   __FILE__);
+   pr_err("failed to allocate char dev region\n");
 }
 
 void __exit rtc_dev_exit(void)
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] tcp: sysctl to disable TCP simultaneous connect

2013-02-14 Thread Kees Cook
On Thu, Feb 14, 2013 at 9:30 PM, Eric W. Biederman
 wrote:
> Kees Cook  writes:
>
>> The patch would not break it -- it defaults the sysctl to staying enabled.
>>
>> If you mean the documentation should be updated, sure, that's easy to do.
>>
>> David: I know you aren't a fan of this patch, but I'd like to try to
>> convince you. :) This leaves the feature enabled and add a toggle for
>> systems (like Chrome OS) that don't want to risk this DoS at all.
>> There are so very many other toggle, I don't see why this one would be
>> a problem to add.
>
> Chrome OS has no plans to implement webrtc?  Last I had read that
> support had been added to the release versions of Chrome, and was in the
> development builds of firefox.  I really don't belive that there are
> many systems that don't intend to run a web browser.

I haven't looked at the internals of webrtc. Are you implying some
feature in it relies on the TCP simultaneous connect?

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 03/11] rtc: rtc-efi: use pr_err()/pr_warn() instead of printk()

2013-02-14 Thread Jingoo Han
On Friday, February 15, 2013 3:04 PM, Venu Byravarasu wrote:
> 
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> > ow...@vger.kernel.org] On Behalf Of Jingoo Han
> > Sent: Friday, February 15, 2013 11:29 AM
> > To: 'Andrew Morton'
> > Cc: linux-kernel@vger.kernel.org; 'Alessandro Zummo'; rtc-
> > li...@googlegroups.com; 'Jingoo Han'
> > Subject: [PATCH 03/11] rtc: rtc-efi: use pr_err()/pr_warn() instead of 
> > printk()
> >
> > Fixed the checkpatch warnings as below:
> >
> >   WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then 
> > pr_err(...
> > to printk(KERN_ERR ...
> >   WARNING: please, no space before tabs
> >
> > Signed-off-by: Jingoo Han 
> > ---
> >  drivers/rtc/rtc-efi.c |   10 ++
> >  1 files changed, 6 insertions(+), 4 deletions(-)
> >
> > eft->timezone   = EFI_UNSPECIFIED_TIMEZONE;
> > @@ -142,7 +144,7 @@ static int efi_set_alarm(struct device *dev, struct
> > rtc_wkalrm *wkalrm)
> >  */
> > status = efi.set_wakeup_time((efi_bool_t)wkalrm->enabled, );
> >
> > -   printk(KERN_WARNING "write status is %d\n", (int)status);
> > +   pr_warn("write status is %d\n", (int)status);
> 
> Why don't you use dev_warn itself?

OK, I will change it.
Thank you.

Best regards,
Jingoo Han

> 
> >
> > return status == EFI_SUCCESS ? 0 : -EINVAL;
> >  }
> > @@ -157,7 +159,7 @@ static int efi_read_time(struct device *dev, struct
> > rtc_time *tm)
> >
> > if (status != EFI_SUCCESS) {
> > /* should never happen */
> > -   printk(KERN_ERR "efitime: can't read time\n");
> > +   pr_err("can't read time\n");
> 
> Why don't you use dev_err itself?
> 
> > return -EINVAL;
> > }
> >
> > --
> > 1.7.2.5
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/


[patch 2/2] x86-64: hook up fincore() syscall

2013-02-14 Thread Johannes Weiner
Signed-off-by: Johannes Weiner 
---
 arch/x86/syscalls/syscall_64.tbl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index 38ae65d..c9ac047 100644
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@ -320,6 +320,7 @@
 31164  process_vm_writev   sys_process_vm_writev
 312common  kcmpsys_kcmp
 313common  finit_modulesys_finit_module
+314common  fincore sys_fincore
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
-- 
1.7.11.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 1/2] mm: fincore()

2013-02-14 Thread Johannes Weiner
On Mon, Feb 11, 2013 at 02:12:39PM -0800, Andrew Morton wrote:
> Also, having to mmap the file to be able to query pagecache state is a
> hack.  Whatever happened to the fincore() patch?

I don't know, but how about this one:

---
From: Johannes Weiner 
Subject: [patch 1/2] mm: fincore()

Provide a syscall to determine whether a given file's pages are cached
in memory.  This is more elegant than mmapping the file for the sole
purpose of using mincore(), and also works on NOMMU.

Signed-off-by: Johannes Weiner 
---
 include/linux/syscalls.h |   2 +
 mm/Makefile  |   2 +-
 mm/fincore.c | 128 +++
 3 files changed, 131 insertions(+), 1 deletion(-)
 create mode 100644 mm/fincore.c

diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 313a8e0..3ceab2a 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -897,4 +897,6 @@ asmlinkage long sys_process_vm_writev(pid_t pid,
 asmlinkage long sys_kcmp(pid_t pid1, pid_t pid2, int type,
 unsigned long idx1, unsigned long idx2);
 asmlinkage long sys_finit_module(int fd, const char __user *uargs, int flags);
+asmlinkage long sys_fincore(unsigned int fd, loff_t start, loff_t len,
+   unsigned char __user * vec);
 #endif
diff --git a/mm/Makefile b/mm/Makefile
index 185a22b..221cdae 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -17,7 +17,7 @@ obj-y := filemap.o mempool.o oom_kill.o 
fadvise.o \
   util.o mmzone.o vmstat.o backing-dev.o \
   mm_init.o mmu_context.o percpu.o slab_common.o \
   compaction.o balloon_compaction.o \
-  interval_tree.o $(mmu-y)
+  interval_tree.o fincore.o $(mmu-y)
 
 obj-y += init-mm.o
 
diff --git a/mm/fincore.c b/mm/fincore.c
new file mode 100644
index 000..d504611
--- /dev/null
+++ b/mm/fincore.c
@@ -0,0 +1,128 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static long do_fincore(struct address_space *mapping, pgoff_t pgstart,
+  unsigned long nr_pages, unsigned char *vec)
+{
+   pgoff_t pgend = pgstart + nr_pages;
+   struct radix_tree_iter iter;
+   void **slot;
+   long nr = 0;
+
+   rcu_read_lock();
+restart:
+   radix_tree_for_each_slot(slot, >page_tree, , pgstart) {
+   unsigned char present;
+   struct page *page;
+
+   /* Handle holes */
+   if (iter.index != pgstart + nr) {
+   if (iter.index < pgend)
+   nr_pages = iter.index - pgstart;
+   break;
+   }
+repeat:
+   page = radix_tree_deref_slot(slot);
+   if (unlikely(!page))
+   continue;
+
+   if (radix_tree_exception(page)) {
+   if (radix_tree_deref_retry(page)) {
+   /*
+* Transient condition which can only trigger
+* when entry at index 0 moves out of or back
+* to root: none yet gotten, safe to restart.
+*/
+   WARN_ON(iter.index);
+   goto restart;
+   }
+   present = 0;
+   } else {
+   if (!page_cache_get_speculative(page))
+   goto repeat;
+
+   /* Has the page moved? */
+   if (unlikely(page != *slot)) {
+   page_cache_release(page);
+   goto repeat;
+   }
+
+   present = PageUptodate(page);
+   page_cache_release(page);
+   }
+   vec[nr] = present;
+
+   if (++nr == nr_pages)
+   break;
+   }
+   rcu_read_unlock();
+
+   if (nr < nr_pages)
+   memset(vec + nr, 0, nr_pages - nr);
+
+   return nr_pages;
+}
+
+/*
+ * The fincore(2) system call.
+ *
+ * fincore() returns the memory residency status of the given file's
+ * pages, in the range [start, start + len].
+ * The status is returned in a vector of bytes.  The least significant
+ * bit of each byte is 1 if the referenced page is in memory, otherwise
+ * it is zero.
+ *
+ * Because the status of a page can change after fincore() checks it
+ * but before it returns to the application, the returned vector may
+ * contain stale information.
+ *
+ * return values:
+ *  zero- success
+ *  -EBADF  - fd isn't a valid open file descriptor
+ *  -EFAULT - vec points to an illegal address
+ *  -EINVAL - start is not a multiple of PAGE_CACHE_SIZE
+ */
+SYSCALL_DEFINE4(fincore, unsigned int, fd, loff_t, start, loff_t, len,
+   

[PATCH] USB: EHCI: make ehci-mv as separate static driver

2013-02-14 Thread Manjunath Goudar
Separate the mv host controller driver from ehci-hcd host code
into its own static driver module.

Signed-off-by: Manjunath Goudar 
Cc: Greg KH 
Cc: Alan Stern 
Cc: Eric Miao 
Cc: Haojian Zhuang 
Cc: Russell King 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/usb/host/Kconfig|2 +-
 drivers/usb/host/Makefile   |1 +
 drivers/usb/host/ehci-hcd.c |6 +---
 drivers/usb/host/ehci-mv.c  |   78 +++
 4 files changed, 38 insertions(+), 49 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8ffbafa..2aa4ece 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -221,7 +221,7 @@ config USB_EHCI_S5P
 Enable support for the S5P SOC's on-chip EHCI controller.
 
 config USB_EHCI_MV
-   bool "EHCI support for Marvell on-chip controller"
+   tristate "EHCI support for Marvell on-chip controller"
depends on USB_EHCI_HCD && (ARCH_PXA || ARCH_MMP)
select USB_EHCI_ROOT_HUB_TT
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 77e0331..d593017 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_SPEAR)+= ehci-spear.o
 obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
 obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
 obj-$(CONFIG_USB_EHCI_S5P)  += ehci-s5p.o
+obj-$(CONFIG_USB_EHCI_MV)   += ehci-mv.o
 obj-$(CONFIG_USB_ISP116X_HCD)  += isp116x-hcd.o
 obj-$(CONFIG_USB_ISP1362_HCD)  += isp1362-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index fa0e665..9cf4d73 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1317,11 +1317,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVERehci_grlib_driver
 #endif
 
-#ifdef CONFIG_USB_EHCI_MV
-#include "ehci-mv.c"
-#definePLATFORM_DRIVER ehci_mv_driver
-#endif
-
 #ifdef CONFIG_MIPS_SEAD3
 #include "ehci-sead3.c"
 #definePLATFORM_DRIVER ehci_hcd_sead3_driver
@@ -1335,6 +1330,7 @@ MODULE_LICENSE ("GPL");
!defined(PLATFORM_DRIVER) && \
!IS_ENABLED(CONFIG_ARCH_AT91) && \
!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
+   !IS_ENABLED(CONFIG_USB_EHCI_MV) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
!defined(XILINX_OF_PLATFORM_DRIVER)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 3065809..0d92437 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -16,8 +16,18 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ehci.h"
+
+#define DRIVER_DESC "EHCI mv driver"
 
 #define CAPLENGTH_MASK (0xff)
+static const char hcd_name[] = "ehci-mv";
+static struct hc_driver __read_mostly mv_ehci_hc_driver;
 
 struct ehci_hcd_mv {
struct usb_hcd *hcd;
@@ -95,48 +105,6 @@ static int mv_ehci_reset(struct usb_hcd *hcd)
return retval;
 }
 
-static const struct hc_driver mv_ehci_hc_driver = {
-   .description = hcd_name,
-   .product_desc = "Marvell EHCI",
-   .hcd_priv_size = sizeof(struct ehci_hcd),
-
-   /*
-* generic hardware linkage
-*/
-   .irq = ehci_irq,
-   .flags = HCD_MEMORY | HCD_USB2,
-
-   /*
-* basic lifecycle operations
-*/
-   .reset = mv_ehci_reset,
-   .start = ehci_run,
-   .stop = ehci_stop,
-   .shutdown = ehci_shutdown,
-
-   /*
-* managing i/o requests and associated device resources
-*/
-   .urb_enqueue = ehci_urb_enqueue,
-   .urb_dequeue = ehci_urb_dequeue,
-   .endpoint_disable = ehci_endpoint_disable,
-   .endpoint_reset = ehci_endpoint_reset,
-   .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-
-   /*
-* scheduling support
-*/
-   .get_frame_number = ehci_get_frame,
-
-   /*
-* root hub support
-*/
-   .hub_status_data = ehci_hub_status_data,
-   .hub_control = ehci_hub_control,
-   .bus_suspend = ehci_bus_suspend,
-   .bus_resume = ehci_bus_resume,
-};
-
 static int mv_ehci_probe(struct platform_device *pdev)
 {
struct mv_usb_platform_data *pdata = pdev->dev.platform_data;
@@ -350,8 +318,32 @@ static struct platform_driver ehci_mv_driver = {
.remove = mv_ehci_remove,
.shutdown = mv_ehci_shutdown,
.driver = {
-  .name = "mv-ehci",
+  .name = hcd_name,
   .bus = _bus_type,
   },
.id_table = ehci_id_table,
 };
+static const struct ehci_driver_overrides mv_overrides __initdata = {
+   .reset = mv_ehci_reset,
+};
+
+static int __init ehci_mv_init(void)
+{
+   if (usb_disabled())
+   return -ENODEV;
+
+   pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+   

[PATCH] USB: EHCI: make ehci-mv a separate driver

2013-02-14 Thread Manjunath Goudar
Separate the mv host controller driver from ehci-hcd host code
into its own driver module.

Signed-off-by: Manjunath Goudar 
Cc: Greg KH 
Cc: Alan Stern 
Cc: Eric Miao 
Cc: Haojian Zhuang 
Cc: Russell King 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/usb/host/Kconfig|2 +-
 drivers/usb/host/Makefile   |1 +
 drivers/usb/host/ehci-hcd.c |6 +---
 drivers/usb/host/ehci-mv.c  |   80 ---
 4 files changed, 40 insertions(+), 49 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8ffbafa..2aa4ece 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -221,7 +221,7 @@ config USB_EHCI_S5P
 Enable support for the S5P SOC's on-chip EHCI controller.
 
 config USB_EHCI_MV
-   bool "EHCI support for Marvell on-chip controller"
+   tristate "EHCI support for Marvell on-chip controller"
depends on USB_EHCI_HCD && (ARCH_PXA || ARCH_MMP)
select USB_EHCI_ROOT_HUB_TT
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 77e0331..d593017 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_SPEAR)+= ehci-spear.o
 obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
 obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
 obj-$(CONFIG_USB_EHCI_S5P)  += ehci-s5p.o
+obj-$(CONFIG_USB_EHCI_MV)   += ehci-mv.o
 obj-$(CONFIG_USB_ISP116X_HCD)  += isp116x-hcd.o
 obj-$(CONFIG_USB_ISP1362_HCD)  += isp1362-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index fa0e665..9cf4d73 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1317,11 +1317,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVERehci_grlib_driver
 #endif
 
-#ifdef CONFIG_USB_EHCI_MV
-#include "ehci-mv.c"
-#definePLATFORM_DRIVER ehci_mv_driver
-#endif
-
 #ifdef CONFIG_MIPS_SEAD3
 #include "ehci-sead3.c"
 #definePLATFORM_DRIVER ehci_hcd_sead3_driver
@@ -1335,6 +1330,7 @@ MODULE_LICENSE ("GPL");
!defined(PLATFORM_DRIVER) && \
!IS_ENABLED(CONFIG_ARCH_AT91) && \
!IS_ENABLED(CONFIG_USB_EHCI_S5P) && \
+   !IS_ENABLED(CONFIG_USB_EHCI_MV) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
!defined(XILINX_OF_PLATFORM_DRIVER)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 3065809..67de419 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -17,7 +17,18 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
+#include "ehci.h"
+
+#define DRIVER_DESC "EHCI mv driver"
+
 #define CAPLENGTH_MASK (0xff)
+static const char hcd_name[] = "ehci-mv";
+static struct hc_driver __read_mostly mv_ehci_hc_driver;
 
 struct ehci_hcd_mv {
struct usb_hcd *hcd;
@@ -95,48 +106,6 @@ static int mv_ehci_reset(struct usb_hcd *hcd)
return retval;
 }
 
-static const struct hc_driver mv_ehci_hc_driver = {
-   .description = hcd_name,
-   .product_desc = "Marvell EHCI",
-   .hcd_priv_size = sizeof(struct ehci_hcd),
-
-   /*
-* generic hardware linkage
-*/
-   .irq = ehci_irq,
-   .flags = HCD_MEMORY | HCD_USB2,
-
-   /*
-* basic lifecycle operations
-*/
-   .reset = mv_ehci_reset,
-   .start = ehci_run,
-   .stop = ehci_stop,
-   .shutdown = ehci_shutdown,
-
-   /*
-* managing i/o requests and associated device resources
-*/
-   .urb_enqueue = ehci_urb_enqueue,
-   .urb_dequeue = ehci_urb_dequeue,
-   .endpoint_disable = ehci_endpoint_disable,
-   .endpoint_reset = ehci_endpoint_reset,
-   .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-
-   /*
-* scheduling support
-*/
-   .get_frame_number = ehci_get_frame,
-
-   /*
-* root hub support
-*/
-   .hub_status_data = ehci_hub_status_data,
-   .hub_control = ehci_hub_control,
-   .bus_suspend = ehci_bus_suspend,
-   .bus_resume = ehci_bus_resume,
-};
-
 static int mv_ehci_probe(struct platform_device *pdev)
 {
struct mv_usb_platform_data *pdata = pdev->dev.platform_data;
@@ -350,8 +319,33 @@ static struct platform_driver ehci_mv_driver = {
.remove = mv_ehci_remove,
.shutdown = mv_ehci_shutdown,
.driver = {
-  .name = "mv-ehci",
+  .name = hcd_name,
   .bus = _bus_type,
   },
.id_table = ehci_id_table,
 };
+static const struct ehci_driver_overrides mv_overrides __initdata = {
+   .reset = mv_ehci_reset,
+};
+
+static int __init ehci_mv_init(void)
+{
+   if (usb_disabled())
+   return -ENODEV;
+
+   pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+   ehci_init_driver(_ehci_hc_driver, 

[PATCH v4 5/5] ARM: davinci: da850: override mmc DT node device name

2013-02-14 Thread Manjunathappa, Prakash
Populate OF_DEV_AUXDATA with desired device name expected by
davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
fails.

Signed-off-by: Manjunathappa, Prakash 
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: c...@laptop.org
Cc: Sekhar Nori 
---
Since v2:
Rebased on top of v3.9/dt-2 branch of linux_davinci and reordered this patch.

 arch/arm/mach-davinci/da8xx-dt.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 5404e92..2b740a9 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -40,6 +40,8 @@ static void __init da8xx_init_irq(void)
 struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
+   OF_DEV_AUXDATA("ti,davinci-mmc-da830", 0x01c4, 
"davinci-mmc-da830.0",
+   NULL),
{}
 };
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v4 4/5] ARM: davinci: da850: add mmc DT entries

2013-02-14 Thread Manjunathappa, Prakash
Add DT entry for MMC. Also add entry for pinmux information.
Tested:
1) Without GPIO card detection and EDMA support as DT support for
   GPIO and EDMA are yet come.
2) By creating/deleting files and mounting/unmounting the partition.

Signed-off-by: Manjunathappa, Prakash 
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: c...@laptop.org
Cc: Sekhar Nori 
---
Since v2:
Remove properties specifying for highspeed card capability.
Since v1:
Removed bitfields for specifying the device capabilty and accomodate
controller revision in compatible field.

 arch/arm/boot/dts/da850-evm.dts |7 +++
 arch/arm/boot/dts/da850.dtsi|   14 ++
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index f712fb6..78c8e54 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -39,6 +39,13 @@
wdt: wdt@1c21000 {
status = "okay";
};
+   mmc0: mmc@1c4 {
+   max-frequency = <5000>;
+   bus-width = <4>;
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   };
};
nand_cs3@6200 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4b2262a..ebe7386 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -67,6 +67,15 @@
0x10 0x2200 0xff00
>;
};
+   mmc0_pins: pinmux_mmc_pins {
+   pinctrl-single,bits = <
+   /* MMCSD0_DAT[3] MMCSD0_DAT[2]
+* MMCSD0_DAT[1] MMCSD0_DAT[0]
+* MMCSD0_CMDMMCSD0_CLK
+*/
+   0x28 0x0022  0x00ff
+   >;
+   };
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -110,6 +119,11 @@
wdt: wdt@1c21000 {
compatible = "ti,davinci-wdt";
reg = <0x21000 0x1000>;
+   };
+   mmc0: mmc@1c4 {
+   compatible = "ti,davinci-mmc-da830";
+   reg = <0x4 0x1000>;
+   interrupts = <16>;
status = "disabled";
};
};
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC] sched: The removal of idle_balance()

2013-02-14 Thread Steven Rostedt
I've been working on cleaning up the scheduler a little and I moved the
call to idle_balance() from directly in the scheduler proper into the
idle class. Benchmarks (well hackbench) improved slightly as I did this.
I was adding some more tweaks and running perf stat on the results when
I made a mistake and notice a drastic change.

My runs looked something like this on my i7 4 core 4 hyperthreads:

[root@bxtest ~]# perf stat -a -r 100  /work/c/hackbench 500
Time: 16.354
Time: 25.299
Time: 20.621
Time: 19.457
Time: 14.484
Time: 7.615
Time: 35.346
Time: 29.366
Time: 18.474
Time: 14.492
Time: 5.660
Time: 25.955
Time: 9.363
Time: 34.834
Time: 18.736
Time: 30.895
Time: 33.827
Time: 11.237
Time: 17.031
Time: 18.615
Time: 29.222
Time: 14.298
Time: 35.798
Time: 7.109
Time: 16.437
Time: 18.782
Time: 4.923
Time: 10.595
Time: 16.685
Time: 9.000
Time: 18.686
Time: 21.355
Time: 10.280
Time: 21.159
Time: 30.955
Time: 15.496
Time: 6.452
Time: 19.625
Time: 20.656
Time: 19.679
Time: 12.484
Time: 31.189
Time: 19.136
Time: 20.763
Time: 11.415
Time: 15.652
Time: 23.935
Time: 28.225
Time: 9.930
Time: 11.658
[...]

With my changes making the average get better by a second or two. The
output from the perf stat looked like this:

 Performance counter stats for '/work/c/hackbench 500' (100 runs):

 199820.045583 task-clock#8.016 CPUs utilized   
 ( +-  5.29% ) [100.00%]
 3,594,264 context-switches  #0.018 M/sec   
 ( +-  5.94% ) [100.00%]
   352,240 cpu-migrations#0.002 M/sec   
 ( +-  3.31% ) [100.00%]
 1,006,732 page-faults   #0.005 M/sec   
 ( +-  0.56% )
   293,801,912,874 cycles#1.470 GHz 
 ( +-  4.20% ) [100.00%]
   261,808,125,109 stalled-cycles-frontend   #   89.11% frontend cycles idle
 ( +-  4.38% ) [100.00%]
stalled-cycles-backend  
   135,521,344,089 instructions  #0.46  insns per cycle
 #1.93  stalled cycles per insn 
 ( +-  4.37% ) [100.00%]
26,198,116,586 branches  #  131.109 M/sec   
 ( +-  4.59% ) [100.00%]
   115,326,812 branch-misses #0.44% of all branches 
 ( +-  4.12% )

  24.929136087 seconds time elapsed 
 ( +-  5.31% )

Again, my patches made slight improvements. Down to 22 and 21 seconds at best.

But then when I made a small tweak, it looked like this:

[root@bxtest ~]# perf stat -a -r 100  /work/c/hackbench 500
Time: 5.820
Time: 28.815
Time: 5.032
Time: 17.151
Time: 8.347
Time: 5.142
Time: 5.138
Time: 18.695
Time: 5.099
Time: 4.994
Time: 5.016
Time: 5.076
Time: 5.049
Time: 21.453
Time: 5.241
Time: 10.498
Time: 5.011
Time: 6.142
Time: 4.953
Time: 5.145
Time: 5.004
Time: 14.848
Time: 5.846
Time: 5.076
Time: 5.826
Time: 5.108
Time: 5.122
Time: 5.254
Time: 5.309
Time: 5.018
Time: 7.561
Time: 5.176
Time: 21.142
Time: 5.063
Time: 5.235
Time: 6.535
Time: 4.993
Time: 5.219
Time: 5.070
Time: 5.232
Time: 5.029
Time: 5.091
Time: 6.092
Time: 5.020
[...]

 Performance counter stats for '/work/c/hackbench 500' (100 runs):

  98258.962617 task-clock#7.998 CPUs utilized   
 ( +- 12.12% ) [100.00%]
 2,572,651 context-switches  #0.026 M/sec   
 ( +-  9.35% ) [100.00%]
   224,004 cpu-migrations#0.002 M/sec   
 ( +-  5.01% ) [100.00%]
   913,813 page-faults   #0.009 M/sec   
 ( +-  0.71% )
   215,927,081,108 cycles#2.198 GHz 
 ( +-  5.48% ) [100.00%]
   189,246,626,321 stalled-cycles-frontend   #   87.64% frontend cycles idle
 ( +-  6.07% ) [100.00%]
stalled-cycles-backend  
   102,965,954,824 instructions  #0.48  insns per cycle
 #1.84  stalled cycles per insn 
 ( +-  5.40% ) [100.00%]
19,280,914,558 branches  #  196.226 M/sec   
 ( +-  5.89% ) [100.00%]
87,284,617 branch-misses #0.45% of all branches 
 ( +-  5.06% )

  12.285025160 seconds time elapsed 
 ( +- 12.14% )

And it consistently looked like that. I thought to myself, geeze! That
tweek did one hell of an improvement. But that tweak should not have, as
I just moved some code around. Things were only being called in
different places.

Looking at my change, I discovered my *bug*, which in this case,
happened to be a true feature. It prevented idle_balance() from ever
being called.

This is a 50% improvement! On a benchmark that stresses the scheduler.
OK, I know that hackbench isn't a real world benchmark, but this got me
thinking. I started looking into the history of idle_balance() and
discovered that it existed 

RE: [PATCH] EnhanceIO ssd caching software

2013-02-14 Thread Amit Kale
Adding Kent and Joe.
-Amit

> -Original Message-
> From: OS Engineering
> Sent: Friday, February 15, 2013 11:33 AM
> To: Greg Kroah-Hartman; LKML; Jens Axboe
> Cc: Darrick J. Wong; Sanoj Unnikrishnan; 王金浦; Amit Kale
> Subject: [PATCH] EnhanceIO ssd caching software
> 
> Hi Greg, Jens,
> 
> We are submitting EnhanceIO(TM) software driver for an inclusion in
> linux staging tree. Present state of this driver is beta. We have been
> posting it for a few weeks, while it was maintained at github. It is
> still being cleaned-up and is being tested by LKML members. Inclusion
> in linux staging tree will make testing and reviewing easier and help a
> future integration in Linux kernel.
> 
> Could you please include it?
> 
> Thanks.
> --
> Amit Kale

PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED



This electronic transmission, and any documents attached hereto, may contain 
confidential, proprietary and/or legally privileged information. The 
information is intended only for use by the recipient named above. If you 
received this electronic message in error, please notify the sender and delete 
the electronic message. Any disclosure, copying, distribution, or use of the 
contents of information received in error is strictly prohibited, and violators 
will be pursued legally.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/11] rtc: rtc-efi: use pr_err()/pr_warn() instead of printk()

2013-02-14 Thread Venu Byravarasu
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Jingoo Han
> Sent: Friday, February 15, 2013 11:29 AM
> To: 'Andrew Morton'
> Cc: linux-kernel@vger.kernel.org; 'Alessandro Zummo'; rtc-
> li...@googlegroups.com; 'Jingoo Han'
> Subject: [PATCH 03/11] rtc: rtc-efi: use pr_err()/pr_warn() instead of 
> printk()
> 
> Fixed the checkpatch warnings as below:
> 
>   WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
> to printk(KERN_ERR ...
>   WARNING: please, no space before tabs
> 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/rtc/rtc-efi.c |   10 ++
>  1 files changed, 6 insertions(+), 4 deletions(-)
> 
>   eft->timezone   = EFI_UNSPECIFIED_TIMEZONE;
> @@ -142,7 +144,7 @@ static int efi_set_alarm(struct device *dev, struct
> rtc_wkalrm *wkalrm)
>*/
>   status = efi.set_wakeup_time((efi_bool_t)wkalrm->enabled, );
> 
> - printk(KERN_WARNING "write status is %d\n", (int)status);
> + pr_warn("write status is %d\n", (int)status);

Why don't you use dev_warn itself? 

> 
>   return status == EFI_SUCCESS ? 0 : -EINVAL;
>  }
> @@ -157,7 +159,7 @@ static int efi_read_time(struct device *dev, struct
> rtc_time *tm)
> 
>   if (status != EFI_SUCCESS) {
>   /* should never happen */
> - printk(KERN_ERR "efitime: can't read time\n");
> + pr_err("can't read time\n");

Why don't you use dev_err itself?  

>   return -EINVAL;
>   }
> 
> --
> 1.7.2.5
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/11] rtc: rtc-cmos: use dev_warn()/dev_dbg() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-cmos.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 9deb9e4..af97c94 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -706,7 +706,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, 
int rtc_irq)
rtc_cmos_int_handler = hpet_rtc_interrupt;
err = hpet_register_irq_handler(cmos_interrupt);
if (err != 0) {
-   printk(KERN_WARNING "hpet_register_irq_handler "
+   dev_warn(dev, "hpet_register_irq_handler "
" failed in rtc_init().");
goto cleanup1;
}
@@ -731,8 +731,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, 
int rtc_irq)
goto cleanup2;
}
 
-   pr_info("%s: %s%s, %zd bytes nvram%s\n",
-   dev_name(_rtc.rtc->dev),
+   dev_info(dev, "%s%s, %zd bytes nvram%s\n",
!is_valid_irq(rtc_irq) ? "no alarms" :
cmos_rtc.mon_alrm ? "alarms up to one year" :
cmos_rtc.day_alrm ? "alarms up to one month" :
@@ -820,8 +819,7 @@ static int cmos_suspend(struct device *dev)
enable_irq_wake(cmos->irq);
}
 
-   pr_debug("%s: suspend%s, ctrl %02x\n",
-   dev_name(_rtc.rtc->dev),
+   dev_dbg(dev, "suspend%s, ctrl %02x\n",
(tmp & RTC_AIE) ? ", alarm may wake" : "",
tmp);
 
@@ -876,9 +874,7 @@ static int cmos_resume(struct device *dev)
spin_unlock_irq(_lock);
}
 
-   pr_debug("%s: resume, ctrl %02x\n",
-   dev_name(_rtc.rtc->dev),
-   tmp);
+   dev_dbg(dev, "resume, ctrl %02x\n", tmp);
 
return 0;
 }
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 10/11] rtc: rtc-pcf8583: use dev_warn() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-pcf8583.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-pcf8583.c b/drivers/rtc/rtc-pcf8583.c
index 3415b8f..aa9bf2b 100644
--- a/drivers/rtc/rtc-pcf8583.c
+++ b/drivers/rtc/rtc-pcf8583.c
@@ -185,7 +185,7 @@ static int pcf8583_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
if (ctrl & (CTRL_STOP | CTRL_HOLD)) {
unsigned char new_ctrl = ctrl & ~(CTRL_STOP | CTRL_HOLD);
 
-   printk(KERN_WARNING "RTC: resetting control %02x -> %02x\n",
+   dev_warn(dev, "RTC: resetting control %02x -> %02x\n",
   ctrl, new_ctrl);
 
if ((err = pcf8583_set_ctrl(client, _ctrl)) < 0)
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 09/11] rtc: rtc-sun4v: use pr_warn() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-sun4v.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-sun4v.c b/drivers/rtc/rtc-sun4v.c
index 5b22610..59b5c2d 100644
--- a/drivers/rtc/rtc-sun4v.c
+++ b/drivers/rtc/rtc-sun4v.c
@@ -3,6 +3,8 @@
  * Copyright (C) 2008 David S. Miller 
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -26,10 +28,10 @@ retry:
udelay(100);
goto retry;
}
-   printk(KERN_WARNING "SUN4V: tod_get() timed out.\n");
+   pr_warn("tod_get() timed out.\n");
return 0;
}
-   printk(KERN_WARNING "SUN4V: tod_get() not supported.\n");
+   pr_warn("tod_get() not supported.\n");
return 0;
 }
 
@@ -53,10 +55,10 @@ retry:
udelay(100);
goto retry;
}
-   printk(KERN_WARNING "SUN4V: tod_set() timed out.\n");
+   pr_warn("tod_set() timed out.\n");
return -EAGAIN;
}
-   printk(KERN_WARNING "SUN4V: tod_set() not supported.\n");
+   pr_warn("tod_set() not supported.\n");
return -EOPNOTSUPP;
 }
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 08/11] rtc: rtc-vr41xx: use dev_info() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-vr41xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/rtc/rtc-vr41xx.c b/drivers/rtc/rtc-vr41xx.c
index 6c3774c..f91be04 100644
--- a/drivers/rtc/rtc-vr41xx.c
+++ b/drivers/rtc/rtc-vr41xx.c
@@ -352,7 +352,7 @@ static int rtc_probe(struct platform_device *pdev)
disable_irq(aie_irq);
disable_irq(pie_irq);
 
-   printk(KERN_INFO "rtc: Real Time Clock of NEC VR4100 series\n");
+   dev_info(>dev, "Real Time Clock of NEC VR4100 series\n");
 
return 0;
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 07/11] rtc: rtc-rs5c313: use pr_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-rs5c313.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-rs5c313.c b/drivers/rtc/rtc-rs5c313.c
index d1aee79..8ca55a6 100644
--- a/drivers/rtc/rtc-rs5c313.c
+++ b/drivers/rtc/rtc-rs5c313.c
@@ -39,6 +39,8 @@
  * 1.13Nobuhiro Iwamatsu: Updata driver.
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -352,8 +354,7 @@ static void rs5c313_check_xstp_bit(void)
tm.tm_year  = 2000 - 1900;
 
rs5c313_rtc_set_time(NULL, );
-   printk(KERN_ERR "RICHO RS5C313: invalid value, resetting to "
-   "1 Jan 2000\n");
+   pr_err("RICHO RS5C313: invalid value, resetting to 1 Jan 
2000\n");
}
RS5C313_CEDISABLE;
ndelay(700);/* CE:L */
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 06/11] rtc: rtc-at91rm9200: use dev_dbg()/dev_err() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-at91rm9200.c |   17 -
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index b6469e2..4a2e451 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -86,7 +86,7 @@ static int at91_rtc_readtime(struct device *dev, struct 
rtc_time *tm)
tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
tm->tm_year = tm->tm_year - 1900;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -100,7 +100,7 @@ static int at91_rtc_settime(struct device *dev, struct 
rtc_time *tm)
 {
unsigned long cr;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -145,7 +145,7 @@ static int at91_rtc_readalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
alrm->enabled = (at91_rtc_read(AT91_RTC_IMR) & AT91_RTC_ALARM)
? 1 : 0;
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
 
@@ -183,7 +183,7 @@ static int at91_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
at91_rtc_write(AT91_RTC_IER, AT91_RTC_ALARM);
}
 
-   pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
+   dev_dbg(dev, "%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __func__,
at91_alarm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour,
tm.tm_min, tm.tm_sec);
 
@@ -192,7 +192,7 @@ static int at91_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
 
 static int at91_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 {
-   pr_debug("%s(): cmd=%08x\n", __func__, enabled);
+   dev_dbg(dev, "%s(): cmd=%08x\n", __func__, enabled);
 
if (enabled) {
at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
@@ -240,7 +240,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void *dev_id)
 
rtc_update_irq(rtc, 1, events);
 
-   pr_debug("%s(): num=%ld, events=0x%02lx\n", __func__,
+   dev_dbg(>dev, "%s(): num=%ld, events=0x%02lx\n", __func__,
events >> 8, events & 0x00FF);
 
return IRQ_HANDLED;
@@ -296,8 +296,7 @@ static int __init at91_rtc_probe(struct platform_device 
*pdev)
IRQF_SHARED,
"at91_rtc", pdev);
if (ret) {
-   printk(KERN_ERR "at91_rtc: IRQ %d already in use.\n",
-   irq);
+   dev_err(>dev, "at91_rtc: IRQ %d already in use.\n", irq);
return ret;
}
 
@@ -315,7 +314,7 @@ static int __init at91_rtc_probe(struct platform_device 
*pdev)
}
platform_set_drvdata(pdev, rtc);
 
-   printk(KERN_INFO "AT91 Real Time Clock driver.\n");
+   dev_info(>dev, "AT91 Real Time Clock driver.\n");
return 0;
 }
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 05/11] rtc: rtc-rs5c372: use dev_dbg()/dev_warn() instead of printk()/pr_debug()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-rs5c372.c |   10 --
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
index 76f565a..581739f 100644
--- a/drivers/rtc/rtc-rs5c372.c
+++ b/drivers/rtc/rtc-rs5c372.c
@@ -311,8 +311,7 @@ static int rs5c_rtc_alarm_irq_enable(struct device *dev, 
unsigned int enabled)
buf &= ~RS5C_CTRL1_AALE;
 
if (i2c_smbus_write_byte_data(client, addr, buf) < 0) {
-   printk(KERN_WARNING "%s: can't update alarm\n",
-   rs5c->rtc->name);
+   dev_warn(dev, "can't update alarm\n");
status = -EIO;
} else
rs5c->regs[RS5C_REG_CTRL1] = buf;
@@ -381,7 +380,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
addr = RS5C_ADDR(RS5C_REG_CTRL1);
buf[0] = rs5c->regs[RS5C_REG_CTRL1] & ~RS5C_CTRL1_AALE;
if (i2c_smbus_write_byte_data(client, addr, buf[0]) < 0) {
-   pr_debug("%s: can't disable alarm\n", rs5c->rtc->name);
+   dev_dbg(dev, "can't disable alarm\n");
return -EIO;
}
rs5c->regs[RS5C_REG_CTRL1] = buf[0];
@@ -395,7 +394,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
for (i = 0; i < sizeof(buf); i++) {
addr = RS5C_ADDR(RS5C_REG_ALARM_A_MIN + i);
if (i2c_smbus_write_byte_data(client, addr, buf[i]) < 0) {
-   pr_debug("%s: can't set alarm time\n", rs5c->rtc->name);
+   dev_dbg(dev, "can't set alarm time\n");
return -EIO;
}
}
@@ -405,8 +404,7 @@ static int rs5c_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
addr = RS5C_ADDR(RS5C_REG_CTRL1);
buf[0] = rs5c->regs[RS5C_REG_CTRL1] | RS5C_CTRL1_AALE;
if (i2c_smbus_write_byte_data(client, addr, buf[0]) < 0)
-   printk(KERN_WARNING "%s: can't enable alarm\n",
-   rs5c->rtc->name);
+   dev_warn(dev, "can't enable alarm\n");
rs5c->regs[RS5C_REG_CTRL1] = buf[0];
}
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 04/11] rtc: rtc-ds2404: use dev_err() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-ds2404.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ds2404.c b/drivers/rtc/rtc-ds2404.c
index 4539e37..b04fc42 100644
--- a/drivers/rtc/rtc-ds2404.c
+++ b/drivers/rtc/rtc-ds2404.c
@@ -70,7 +70,7 @@ static int ds2404_gpio_map(struct ds2404 *chip, struct 
platform_device *pdev,
for (i = 0; i < ARRAY_SIZE(ds2404_gpio); i++) {
err = gpio_request(ds2404_gpio[i].gpio, ds2404_gpio[i].name);
if (err) {
-   printk(KERN_ERR "error mapping gpio %s: %d\n",
+   dev_err(>dev, "error mapping gpio %s: %d\n",
ds2404_gpio[i].name, err);
goto err_request;
}
@@ -177,7 +177,7 @@ static void ds2404_write_memory(struct device *dev, u16 
offset,
 
for (i = 0; i < length; i++) {
if (out[i] != ds2404_read_byte(dev)) {
-   printk(KERN_ERR "read invalid data\n");
+   dev_err(dev, "read invalid data\n");
return;
}
}
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 03/11] rtc: rtc-efi: use pr_err()/pr_warn() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warnings as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...
  WARNING: please, no space before tabs

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-efi.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index c9f890b..d4755dc 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -13,6 +13,8 @@
  *
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -47,7 +49,7 @@ compute_wday(efi_time_t *eft)
int ndays = 0;
 
if (eft->year < 1998) {
-   printk(KERN_ERR "efirtc: EFI year < 1998, invalid date\n");
+   pr_err("EFI year < 1998, invalid date\n");
return -1;
}
 
@@ -70,7 +72,7 @@ convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
eft->day= wtime->tm_mday;
eft->hour   = wtime->tm_hour;
eft->minute = wtime->tm_min;
-   eft->second = wtime->tm_sec;
+   eft->second = wtime->tm_sec;
eft->nanosecond = 0;
eft->daylight   = wtime->tm_isdst ? EFI_ISDST : 0;
eft->timezone   = EFI_UNSPECIFIED_TIMEZONE;
@@ -142,7 +144,7 @@ static int efi_set_alarm(struct device *dev, struct 
rtc_wkalrm *wkalrm)
 */
status = efi.set_wakeup_time((efi_bool_t)wkalrm->enabled, );
 
-   printk(KERN_WARNING "write status is %d\n", (int)status);
+   pr_warn("write status is %d\n", (int)status);
 
return status == EFI_SUCCESS ? 0 : -EINVAL;
 }
@@ -157,7 +159,7 @@ static int efi_read_time(struct device *dev, struct 
rtc_time *tm)
 
if (status != EFI_SUCCESS) {
/* should never happen */
-   printk(KERN_ERR "efitime: can't read time\n");
+   pr_err("can't read time\n");
return -EINVAL;
}
 
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 02/11] rtc: max77686: use dev_info() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/rtc-max77686.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 2da0855..abe27c0 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -507,7 +507,7 @@ static int max77686_rtc_probe(struct platform_device *pdev)
struct max77686_rtc_info *info;
int ret, virq;
 
-   printk(KERN_INFO "%s\n", __func__);
+   dev_info(>dev, "%s\n", __func__);
 
info = kzalloc(sizeof(struct max77686_rtc_info), GFP_KERNEL);
if (!info)
@@ -546,7 +546,7 @@ static int max77686_rtc_probe(struct platform_device *pdev)
_rtc_ops, THIS_MODULE);
 
if (IS_ERR(info->rtc_dev)) {
-   printk(KERN_INFO "%s: fail\n", __func__);
+   dev_info(>dev, "%s: fail\n", __func__);
 
ret = PTR_ERR(info->rtc_dev);
dev_err(>dev, "Failed to register RTC device: %d\n", ret);
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 01/11] rtc: use pr_err()/pr_warn() instead of printk()

2013-02-14 Thread Jingoo Han
Fixed the checkpatch warning as below:

  WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  
to printk(KERN_ERR ...

Signed-off-by: Jingoo Han 
---
 drivers/rtc/class.c   |4 +++-
 drivers/rtc/rtc-dev.c |7 ---
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 26388f1..9b742d3 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -11,6 +11,8 @@
  * published by the Free Software Foundation.
 */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -261,7 +263,7 @@ static int __init rtc_init(void)
 {
rtc_class = class_create(THIS_MODULE, "rtc");
if (IS_ERR(rtc_class)) {
-   printk(KERN_ERR "%s: couldn't create class\n", __FILE__);
+   pr_err("couldn't create class\n");
return PTR_ERR(rtc_class);
}
rtc_class->suspend = rtc_suspend;
diff --git a/drivers/rtc/rtc-dev.c b/drivers/rtc/rtc-dev.c
index 9a86b4b..471c30e 100644
--- a/drivers/rtc/rtc-dev.c
+++ b/drivers/rtc/rtc-dev.c
@@ -11,6 +11,8 @@
  * published by the Free Software Foundation.
 */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -480,7 +482,7 @@ void rtc_dev_prepare(struct rtc_device *rtc)
 void rtc_dev_add_device(struct rtc_device *rtc)
 {
if (cdev_add(>char_dev, rtc->dev.devt, 1))
-   printk(KERN_WARNING "%s: failed to add char device %d:%d\n",
+   pr_warn("%s: failed to add char device %d:%d\n",
rtc->name, MAJOR(rtc_devt), rtc->id);
else
pr_debug("%s: dev (%d:%d)\n", rtc->name,
@@ -499,8 +501,7 @@ void __init rtc_dev_init(void)
 
err = alloc_chrdev_region(_devt, 0, RTC_DEV_MAX, "rtc");
if (err < 0)
-   printk(KERN_ERR "%s: failed to allocate char dev region\n",
-   __FILE__);
+   pr_err("failed to allocate char dev region\n");
 }
 
 void __exit rtc_dev_exit(void)
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/4] gpiolib: move comment to right function

2013-02-14 Thread Alexandre Courbot
This comment applies to gpio_to_chip(), not gpiod_to_chip().

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/gpiolib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a33bfc2..c2534d6 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -172,12 +172,12 @@ static int gpio_ensure_requested(struct gpio_desc *desc)
return 0;
 }
 
-/* caller holds gpio_lock *OR* gpio is marked as requested */
 static struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc)
 {
return desc ? desc->chip : NULL;
 }
 
+/* caller holds gpio_lock *OR* gpio is marked as requested */
 struct gpio_chip *gpio_to_chip(unsigned gpio)
 {
return gpiod_to_chip(gpio_to_desc(gpio));
-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 4/4] gpiolib: rename local offset variables to "hwgpio"

2013-02-14 Thread Alexandre Courbot
Their value being obtained by gpio_chip_hwgpio(), this better reflects
their use.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/gpiolib.c | 70 +-
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index c2534d6..6e38dfd 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -72,7 +72,7 @@ struct gpio_desc {
 };
 static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
 
-#define GPIO_OFFSET_VALID(chip, offset) (offset >= 0 && offset < chip->ngpio)
+#define GPIO_HWNUM_VALID(chip, hwgpio) (hwgpio >= 0 && hwgpio < chip->ngpio)
 
 static LIST_HEAD(gpio_chips);
 
@@ -211,16 +211,16 @@ static int gpiochip_find_base(int ngpio)
 static int gpiod_get_direction(const struct gpio_desc *desc)
 {
struct gpio_chip*chip;
-   unsignedoffset;
+   unsignedhwgpio;
int status = -EINVAL;
 
chip = gpiod_to_chip(desc);
-   offset = gpio_chip_hwgpio(desc);
+   hwgpio = gpio_chip_hwgpio(desc);
 
if (!chip->get_direction)
return status;
 
-   status = chip->get_direction(chip, offset);
+   status = chip->get_direction(chip, hwgpio);
if (status > 0) {
/* GPIOF_DIR_IN, or other positive */
status = 1;
@@ -756,7 +756,7 @@ static int gpiod_export(struct gpio_desc *desc, bool 
direction_may_change)
int status;
const char  *ioname = NULL;
struct device   *dev;
-   int offset;
+   int hwgpio;
 
/* can't export until sysfs is available ... */
if (!gpio_class.p) {
@@ -787,9 +787,9 @@ static int gpiod_export(struct gpio_desc *desc, bool 
direction_may_change)
direction_may_change = false;
spin_unlock_irqrestore(_lock, flags);
 
-   offset = gpio_chip_hwgpio(desc);
-   if (desc->chip->names && desc->chip->names[offset])
-   ioname = desc->chip->names[offset];
+   hwgpio = gpio_chip_hwgpio(desc);
+   if (desc->chip->names && desc->chip->names[hwgpio])
+   ioname = desc->chip->names[hwgpio];
 
dev = device_create(_class, desc->chip->dev, MKDEV(0, 0),
desc, ioname ? ioname : "gpio%u",
@@ -1596,7 +1596,7 @@ const char *gpiochip_is_requested(struct gpio_chip *chip, 
unsigned offset)
 {
struct gpio_desc *desc;
 
-   if (!GPIO_OFFSET_VALID(chip, offset))
+   if (!GPIO_HWNUM_VALID(chip, offset))
return NULL;
 
desc = >desc[offset];
@@ -1626,7 +1626,7 @@ static int gpiod_direction_input(struct gpio_desc *desc)
unsigned long   flags;
struct gpio_chip*chip;
int status = -EINVAL;
-   int offset;
+   int hwgpio;
 
if (!desc) {
pr_warn("%s: invalid GPIO\n", __func__);
@@ -1648,9 +1648,9 @@ static int gpiod_direction_input(struct gpio_desc *desc)
 
might_sleep_if(chip->can_sleep);
 
-   offset = gpio_chip_hwgpio(desc);
+   hwgpio = gpio_chip_hwgpio(desc);
if (status) {
-   status = chip->request(chip, offset);
+   status = chip->request(chip, hwgpio);
if (status < 0) {
pr_debug("GPIO-%d: chip request fail, %d\n",
desc_to_gpio(desc), status);
@@ -1661,7 +1661,7 @@ static int gpiod_direction_input(struct gpio_desc *desc)
}
}
 
-   status = chip->direction_input(chip, offset);
+   status = chip->direction_input(chip, hwgpio);
if (status == 0)
clear_bit(FLAG_IS_OUT, >flags);
 
@@ -1687,7 +1687,7 @@ static int gpiod_direction_output(struct gpio_desc *desc, 
int value)
unsigned long   flags;
struct gpio_chip*chip;
int status = -EINVAL;
-   int offset;
+   int hwgpio;
 
if (!desc) {
pr_warn("%s: invalid GPIO\n", __func__);
@@ -1717,9 +1717,9 @@ static int gpiod_direction_output(struct gpio_desc *desc, 
int value)
 
might_sleep_if(chip->can_sleep);
 
-   offset = gpio_chip_hwgpio(desc);
+   hwgpio = gpio_chip_hwgpio(desc);
if (status) {
-   status = chip->request(chip, offset);
+   status = chip->request(chip, hwgpio);
if (status < 0) {
pr_debug("GPIO-%d: chip request fail, %d\n",
desc_to_gpio(desc), status);
@@ -1730,7 +1730,7 @@ static int gpiod_direction_output(struct gpio_desc *desc, 
int value)
}
}
 
-   status = chip->direction_output(chip, offset, value);
+   status = chip->direction_output(chip, hwgpio, value);
if (status == 0)

[PATCH 1/4] gpiolib: check descriptors validity before use

2013-02-14 Thread Alexandre Courbot
Some functions dereferenced their GPIO descriptor argument without
checking its validity first, potentially leading to an oops when given
an invalid argument.

This patch also makes gpio_get_value() more resilient when given an
invalid GPIO, returning 0 instead of silently crashing.

Signed-off-by: Alexandre Courbot 
Cc: Ryan Mallon 
---
 drivers/gpio/gpiolib.c | 112 -
 1 file changed, 65 insertions(+), 47 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index fff9786..1a8a7a8 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -174,7 +174,7 @@ static int gpio_ensure_requested(struct gpio_desc *desc)
 /* caller holds gpio_lock *OR* gpio is marked as requested */
 static struct gpio_chip *gpiod_to_chip(struct gpio_desc *desc)
 {
-   return desc->chip;
+   return desc ? desc->chip : NULL;
 }
 
 struct gpio_chip *gpio_to_chip(unsigned gpio)
@@ -654,6 +654,11 @@ static ssize_t export_store(struct class *class,
goto done;
 
desc = gpio_to_desc(gpio);
+   /* reject invalid GPIOs */
+   if (!desc) {
+   pr_warn("%s: invalid GPIO %ld\n", __func__, gpio);
+   return -EINVAL;
+   }
 
/* No extra locking here; FLAG_SYSFS just signifies that the
 * request and export were done by on behalf of userspace, so
@@ -690,12 +695,14 @@ static ssize_t unexport_store(struct class *class,
if (status < 0)
goto done;
 
-   status = -EINVAL;
-
desc = gpio_to_desc(gpio);
/* reject bogus commands (gpio_unexport ignores them) */
-   if (!desc)
-   goto done;
+   if (!desc) {
+   pr_warn("%s: invalid GPIO %ld\n", __func__, gpio);
+   return -EINVAL;
+   }
+
+   status = -EINVAL;
 
/* No extra locking here; FLAG_SYSFS just signifies that the
 * request and export were done by on behalf of userspace, so
@@ -846,8 +853,10 @@ static int gpiod_export_link(struct device *dev, const 
char *name,
 {
int status = -EINVAL;
 
-   if (!desc)
-   goto done;
+   if (!desc) {
+   pr_warn("%s: invalid GPIO\n", __func__);
+   return -EINVAL;
+   }
 
mutex_lock(_lock);
 
@@ -865,7 +874,6 @@ static int gpiod_export_link(struct device *dev, const char 
*name,
 
mutex_unlock(_lock);
 
-done:
if (status)
pr_debug("%s: gpio%d status %d\n", __func__, desc_to_gpio(desc),
 status);
@@ -896,8 +904,10 @@ static int gpiod_sysfs_set_active_low(struct gpio_desc 
*desc, int value)
struct device   *dev = NULL;
int status = -EINVAL;
 
-   if (!desc)
-   goto done;
+   if (!desc) {
+   pr_warn("%s: invalid GPIO\n", __func__);
+   return -EINVAL;
+   }
 
mutex_lock(_lock);
 
@@ -914,7 +924,6 @@ static int gpiod_sysfs_set_active_low(struct gpio_desc 
*desc, int value)
 unlock:
mutex_unlock(_lock);
 
-done:
if (status)
pr_debug("%s: gpio%d status %d\n", __func__, desc_to_gpio(desc),
 status);
@@ -940,8 +949,8 @@ static void gpiod_unexport(struct gpio_desc *desc)
struct device   *dev = NULL;
 
if (!desc) {
-   status = -EINVAL;
-   goto done;
+   pr_warn("%s: invalid GPIO\n", __func__);
+   return;
}
 
mutex_lock(_lock);
@@ -962,7 +971,7 @@ static void gpiod_unexport(struct gpio_desc *desc)
device_unregister(dev);
put_device(dev);
}
-done:
+
if (status)
pr_debug("%s: gpio%d status %d\n", __func__, desc_to_gpio(desc),
 status);
@@ -1384,12 +1393,13 @@ static int gpiod_request(struct gpio_desc *desc, const 
char *label)
int status = -EPROBE_DEFER;
unsigned long   flags;
 
-   spin_lock_irqsave(_lock, flags);
-
if (!desc) {
-   status = -EINVAL;
-   goto done;
+   pr_warn("%s: invalid GPIO\n", __func__);
+   return -EINVAL;
}
+
+   spin_lock_irqsave(_lock, flags);
+
chip = desc->chip;
if (chip == NULL)
goto done;
@@ -1432,8 +1442,7 @@ static int gpiod_request(struct gpio_desc *desc, const 
char *label)
 done:
if (status)
pr_debug("_gpio_request: gpio-%d (%s) status %d\n",
-desc ? desc_to_gpio(desc) : -1,
-label ? : "?", status);
+desc_to_gpio(desc), label ? : "?", status);
spin_unlock_irqrestore(_lock, flags);
return status;
 }
@@ -1616,10 +1625,13 @@ static int gpiod_direction_input(struct gpio_desc *desc)
int status = -EINVAL;
int   

[PATCH 2/4] gpiolib: use const parameters when possible

2013-02-14 Thread Alexandre Courbot
Constify descriptor parameter of gpiod_* functions for those that
should obviously not modify it. This includes value or direction get,
cansleep, and IRQ number query.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/gpiolib.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1a8a7a8..a33bfc2 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -88,13 +88,14 @@ static int gpiod_request(struct gpio_desc *desc, const char 
*label);
 static void gpiod_free(struct gpio_desc *desc);
 static int gpiod_direction_input(struct gpio_desc *desc);
 static int gpiod_direction_output(struct gpio_desc *desc, int value);
+static int gpiod_get_direction(const struct gpio_desc *desc);
 static int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce);
-static int gpiod_get_value_cansleep(struct gpio_desc *desc);
+static int gpiod_get_value_cansleep(const struct gpio_desc *desc);
 static void gpiod_set_value_cansleep(struct gpio_desc *desc, int value);
-static int gpiod_get_value(struct gpio_desc *desc);
+static int gpiod_get_value(const struct gpio_desc *desc);
 static void gpiod_set_value(struct gpio_desc *desc, int value);
-static int gpiod_cansleep(struct gpio_desc *desc);
-static int gpiod_to_irq(struct gpio_desc *desc);
+static int gpiod_cansleep(const struct gpio_desc *desc);
+static int gpiod_to_irq(const struct gpio_desc *desc);
 static int gpiod_export(struct gpio_desc *desc, bool direction_may_change);
 static int gpiod_export_link(struct device *dev, const char *name,
 struct gpio_desc *desc);
@@ -172,7 +173,7 @@ static int gpio_ensure_requested(struct gpio_desc *desc)
 }
 
 /* caller holds gpio_lock *OR* gpio is marked as requested */
-static struct gpio_chip *gpiod_to_chip(struct gpio_desc *desc)
+static struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc)
 {
return desc ? desc->chip : NULL;
 }
@@ -207,7 +208,7 @@ static int gpiochip_find_base(int ngpio)
 }
 
 /* caller ensures gpio is valid and requested, chip->get_direction may sleep  
*/
-static int gpiod_get_direction(struct gpio_desc *desc)
+static int gpiod_get_direction(const struct gpio_desc *desc)
 {
struct gpio_chip*chip;
unsignedoffset;
@@ -223,11 +224,13 @@ static int gpiod_get_direction(struct gpio_desc *desc)
if (status > 0) {
/* GPIOF_DIR_IN, or other positive */
status = 1;
-   clear_bit(FLAG_IS_OUT, >flags);
+   /* FLAG_IS_OUT is just a cache of the result of get_direction(),
+* so it does not affect constness per se */
+   clear_bit(FLAG_IS_OUT, &((struct gpio_desc *)desc)->flags);
}
if (status == 0) {
/* GPIOF_DIR_OUT */
-   set_bit(FLAG_IS_OUT, >flags);
+   set_bit(FLAG_IS_OUT, &((struct gpio_desc *)desc)->flags);
}
return status;
 }
@@ -263,7 +266,7 @@ static DEFINE_MUTEX(sysfs_lock);
 static ssize_t gpio_direction_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-   struct gpio_desc*desc = dev_get_drvdata(dev);
+   const struct gpio_desc  *desc = dev_get_drvdata(dev);
ssize_t status;
 
mutex_lock(_lock);
@@ -1830,7 +1833,7 @@ EXPORT_SYMBOL_GPL(gpio_set_debounce);
  * It returns the zero or nonzero value provided by the associated
  * gpio_chip.get() method; or zero if no such method is provided.
  */
-static int gpiod_get_value(struct gpio_desc *desc)
+static int gpiod_get_value(const struct gpio_desc *desc)
 {
struct gpio_chip*chip;
int value;
@@ -1948,7 +1951,7 @@ EXPORT_SYMBOL_GPL(__gpio_set_value);
  * This is used directly or indirectly to implement gpio_cansleep().  It
  * returns nonzero if access reading or writing the GPIO value can sleep.
  */
-static int gpiod_cansleep(struct gpio_desc *desc)
+static int gpiod_cansleep(const struct gpio_desc *desc)
 {
if (!desc)
return 0;
@@ -1971,7 +1974,7 @@ EXPORT_SYMBOL_GPL(__gpio_cansleep);
  * It returns the number of the IRQ signaled by this (input) GPIO,
  * or a negative errno.
  */
-static int gpiod_to_irq(struct gpio_desc *desc)
+static int gpiod_to_irq(const struct gpio_desc *desc)
 {
struct gpio_chip*chip;
int offset;
@@ -1994,7 +1997,7 @@ EXPORT_SYMBOL_GPL(__gpio_to_irq);
  * Common examples include ones connected to I2C or SPI chips.
  */
 
-static int gpiod_get_value_cansleep(struct gpio_desc *desc)
+static int gpiod_get_value_cansleep(const struct gpio_desc *desc)
 {
struct gpio_chip*chip;
int value;
-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/4] gpiolib: some fixup patches

2013-02-14 Thread Alexandre Courbot
This short series is a fixup to patch 6/9 of my previous series ("gpiolib: use
descriptors internally"), which mainly addresses issues raised by Linus W. in
this patch and a few other minor ones caught while proof-reading gpiolib.

First patch is the most significant. It mostly avoids oopses when passing an
invalid GPIO to some functions. Also gpio_get/set_value*() now return 0 when
given an invalid GPIO number instead of oopsing. I tend to think that's an
improvement, but if it's not please let me know.

Ideally these patches should be melded into the above-mentioned patch since
they were intended to become a new revision, but I leave that decision to
Grant's discretion.

This patchset has been tested on Tegra 2/Ventana with a GPIO backlight driver
and the sysfs interface.

Changes from v1:
- as suggested by Ryan Mallon, add a dedicated control flow for signaling
  invalid GPIOs to avoid meaningless error messages and ugly ternary operators
- use pr_warn instead of pr_debug to signal invalid GPIOs
- do descriptors validity check before acquiring any lock

Alexandre Courbot (4):
  gpiolib: check descriptors validity before use
  gpiolib: use const parameters when possible
  gpiolib: move comment to right function
  gpiolib: rename local offset variables to "hwgpio"

 drivers/gpio/gpiolib.c | 213 +++--
 1 file changed, 117 insertions(+), 96 deletions(-)

-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] tcp: sysctl to disable TCP simultaneous connect

2013-02-14 Thread Eric W. Biederman
Kees Cook  writes:

> The patch would not break it -- it defaults the sysctl to staying enabled.
>
> If you mean the documentation should be updated, sure, that's easy to do.
>
> David: I know you aren't a fan of this patch, but I'd like to try to
> convince you. :) This leaves the feature enabled and add a toggle for
> systems (like Chrome OS) that don't want to risk this DoS at all.
> There are so very many other toggle, I don't see why this one would be
> a problem to add.

Chrome OS has no plans to implement webrtc?  Last I had read that
support had been added to the release versions of Chrome, and was in the
development builds of firefox.  I really don't belive that there are
many systems that don't intend to run a web browser.

Eric


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


linux-next: build warning after merge of the idle tree

2013-02-14 Thread Stephen Rothwell
Hi Len,

After merging the idle tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

arch/x86/kernel/smpboot.c: In function 'mwait_play_dead':
arch/x86/kernel/smpboot.c:1370:22: warning: unused variable 'c' 
[-Wunused-variable]

Introduced by commit 69fb3676df33 ("x86 idle: remove mwait_idle() and
"idle=mwait" cmdline param").

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpcuKnMAqzOm.pgp
Description: PGP signature


linux-next: build warning after merge of the char-misc tree

2013-02-14 Thread Stephen Rothwell
Hi all,

After merging the char-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/w1/slaves/w1_therm.c: In function 'w1_therm_read':
drivers/w1/slaves/w1_therm.c:245:15: warning: 'crc' may be used uninitialized 
in this function [-Wuninitialized]

Its a false positive, but it was introduced by commit 867ff9880d5d
("w1_therm: Retries: remove old code add CRC")
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp_rJrzdIMBZ.pgp
Description: PGP signature


Re: [PATCH v2 1/1] eventfd: implementation of EFD_MASK flag

2013-02-14 Thread Andrew Morton
On Fri, 15 Feb 2013 04:42:27 +0100 Martin Sustrik  wrote:

> > This is a non-back-compatible userspace interface change.  A procfs
> > file which previously displayed
> >
> > eventfd-count: 
> >
> > can now also display
> >
> > eventfd-mask: 
> >
> > So existing userspace could misbehave.
> >
> > Please fully describe the proposed interface change in the changelog.
> > That description should include the full pathname of the procfs file
> > and example before-and-after output and a discussion of whether and why
> > the risk to existing userspace is acceptable.
> 
> I am not sure what the policy is here. Is not printing out the state of 
> the object acceptable way to maintain backward compatibility? If not so, 
> does new type of object require new procfs file, which, AFAIU, is the 
> only way to retain full backward compatibility?

Adding a new file is the only way I can think of to preserve the API. 
But from Andy's comment is sounds like we don't have to worry a lot
about back-compatibility.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: manual merge of the driver-core tree with the tree

2013-02-14 Thread Greg KH
On Fri, Feb 15, 2013 at 04:01:24PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/net/wireless/rtlwifi/Kconfig between commit 06e7cda3ce30
> ("rtlwifi: Rework Kconfig") from the wireless-next tree and commit
> 6cba014857f4 ("drivers/net/wireless/rtlwifi: remove depends on
> CONFIG_EXPERIMENTAL") from the driver-core tree.
> 
> I fixed it up (the former is a superset of the latter, so I used that)
> and can carry the fix as necessary (no action is required).

That sounds fine, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 5/7] staging/ozwpan: Fix sparse warning Using plain integer as NULL pointer

2013-02-14 Thread Peter Huewe
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing the offending 0s with NULL.

Signed-off-by: Peter Huewe 
---
 drivers/staging/ozwpan/ozcdev.c |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 64913ae..5205617 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -97,7 +97,7 @@ ssize_t oz_cdev_read(struct file *filp, char __user *buf, 
size_t count,
int ix;
 
struct oz_pd *pd;
-   struct oz_serial_ctx *ctx = 0;
+   struct oz_serial_ctx *ctx = NULL;
 
spin_lock_bh(_cdev.lock);
pd = g_cdev.active_pd;
@@ -147,7 +147,7 @@ ssize_t oz_cdev_write(struct file *filp, const char __user 
*buf, size_t count,
 {
struct oz_pd *pd;
struct oz_elt_buf *eb;
-   struct oz_elt_info *ei = 0;
+   struct oz_elt_info *ei = NULL;
struct oz_elt *elt;
struct oz_app_hdr *app_hdr;
struct oz_serial_ctx *ctx;
@@ -182,7 +182,7 @@ ssize_t oz_cdev_write(struct file *filp, const char __user 
*buf, size_t count,
ctx->tx_seq_num = 1;
spin_lock(>lock);
if (oz_queue_elt_info(eb, 0, 0, ei) == 0)
-   ei = 0;
+   ei = NULL;
spin_unlock(>lock);
}
spin_unlock_bh(>app_lock[OZ_APPID_USB-1]);
@@ -217,7 +217,7 @@ static int oz_set_active_pd(u8 *addr)
if (is_zero_ether_addr(addr)) {
spin_lock_bh(_cdev.lock);
pd = g_cdev.active_pd;
-   g_cdev.active_pd = 0;
+   g_cdev.active_pd = NULL;
memset(g_cdev.active_addr, 0,
sizeof(g_cdev.active_addr));
spin_unlock_bh(_cdev.lock);
@@ -385,7 +385,7 @@ int oz_cdev_deregister(void)
  */
 int oz_cdev_init(void)
 {
-   oz_event_log(OZ_EVT_SERVICE, 1, OZ_APPID_SERIAL, 0, 0);
+   oz_event_log(OZ_EVT_SERVICE, 1, OZ_APPID_SERIAL, NULL, 0);
oz_app_enable(OZ_APPID_SERIAL, 1);
return 0;
 }
@@ -394,7 +394,7 @@ int oz_cdev_init(void)
  */
 void oz_cdev_term(void)
 {
-   oz_event_log(OZ_EVT_SERVICE, 2, OZ_APPID_SERIAL, 0, 0);
+   oz_event_log(OZ_EVT_SERVICE, 2, OZ_APPID_SERIAL, NULL, 0);
oz_app_enable(OZ_APPID_SERIAL, 0);
 }
 
/*--
@@ -403,8 +403,8 @@ void oz_cdev_term(void)
 int oz_cdev_start(struct oz_pd *pd, int resume)
 {
struct oz_serial_ctx *ctx;
-   struct oz_serial_ctx *old_ctx = 0;
-   oz_event_log(OZ_EVT_SERVICE, 3, OZ_APPID_SERIAL, 0, resume);
+   struct oz_serial_ctx *old_ctx = NULL;
+   oz_event_log(OZ_EVT_SERVICE, 3, OZ_APPID_SERIAL, NULL, resume);
if (resume) {
oz_trace("Serial service resumed.\n");
return 0;
@@ -440,22 +440,22 @@ int oz_cdev_start(struct oz_pd *pd, int resume)
 void oz_cdev_stop(struct oz_pd *pd, int pause)
 {
struct oz_serial_ctx *ctx;
-   oz_event_log(OZ_EVT_SERVICE, 4, OZ_APPID_SERIAL, 0, pause);
+   oz_event_log(OZ_EVT_SERVICE, 4, OZ_APPID_SERIAL, NULL, pause);
if (pause) {
oz_trace("Serial service paused.\n");
return;
}
spin_lock_bh(>app_lock[OZ_APPID_SERIAL-1]);
ctx = (struct oz_serial_ctx *)pd->app_ctx[OZ_APPID_SERIAL-1];
-   pd->app_ctx[OZ_APPID_SERIAL-1] = 0;
+   pd->app_ctx[OZ_APPID_SERIAL-1] = NULL;
spin_unlock_bh(>app_lock[OZ_APPID_SERIAL-1]);
if (ctx)
oz_cdev_release_ctx(ctx);
spin_lock(_cdev.lock);
if (pd == g_cdev.active_pd)
-   g_cdev.active_pd = 0;
+   g_cdev.active_pd = NULL;
else
-   pd = 0;
+   pd = NULL;
spin_unlock(_cdev.lock);
if (pd) {
oz_pd_put(pd);
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3] media: ths7353: add support for ths7353 video amplifier

2013-02-14 Thread Prabhakar Lad
Hi Mauro,

Thanks for the review.

On Thu, Feb 14, 2013 at 12:47 AM, Mauro Carvalho Chehab
 wrote:
> Em Thu,  7 Feb 2013 11:10:28 +0530
> Prabhakar lad  escreveu:
>
>> From: Lad, Prabhakar 
>>
>> The patch adds support for THS7353 video amplifier.
>> The the THS7353 amplifier is very much similar to the
>> existing THS7303 video amplifier driver.
>> This patch appropriately makes changes to the existing
>> ths7303 driver and adds support for the THS7353.
>> This patch also adds V4L2_IDENT_THS7353 for the THS7353
>> chip and appropriate changes to Kconfig file for building.
>>
>> Signed-off-by: Lad, Prabhakar 
>> Signed-off-by: Hans Verkuil 
>> Signed-off-by: Martin Bugge 
>> Cc: Chaithrika U S 
>> ---
>>  Changes for v3:
>>  1: Fixed review comments pointed out by Hans.
>>
>>  Changes for v2:
>>  1: Merged the driver in existing ths7303 driver.
>>  2: Merged the patch which adds the chip indent in same patch.
>>
>>  drivers/media/i2c/Kconfig   |6 +-
>>  drivers/media/i2c/ths7303.c |  353 
>> ---
>>  include/media/ths7303.h |   42 +
>>  include/media/v4l2-chip-ident.h |3 +
>>  4 files changed, 343 insertions(+), 61 deletions(-)
>>  create mode 100644 include/media/ths7303.h
>>
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index ecdf7e3..bd08541 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -576,10 +576,10 @@ config VIDEO_UPD64083
>>  comment "Miscelaneous helper chips"
>>
>>  config VIDEO_THS7303
>> - tristate "THS7303 Video Amplifier"
>> - depends on I2C
>> + tristate "THS7303/53 Video Amplifier"
>> + depends on VIDEO_V4L2 && I2C
>>   help
>> -   Support for TI THS7303 video amplifier
>> +   Support for TI THS7303/53 video amplifier
>>
>> To compile this driver as a module, choose M here: the
>> module will be called ths7303.
>> diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
>> index e747524..7300abc 100644
>> --- a/drivers/media/i2c/ths7303.c
>> +++ b/drivers/media/i2c/ths7303.c
>> @@ -1,7 +1,15 @@
>>  /*
>> - * ths7303- THS7303 Video Amplifier driver
>> + * ths7303/53- THS7303/53 Video Amplifier driver
>>   *
>>   * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
>> + * Copyright 2013 Cisco Systems, Inc. and/or its affiliates.
>> + *
>> + * Author: Chaithrika U S 
>> + *
>> + * Contributors:
>> + * Lad, Prabhakar 
>> + * Hans Verkuil 
>> + * Martin Bugge 
>>   *
>>   * This program is free software; you can redistribute it and/or
>>   * modify it under the terms of the GNU General Public License as
>> @@ -13,25 +21,27 @@
>>   * GNU General Public License for more details.
>>   */
>>
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>>  #include 
>> -#include 
>> -#include 
>>  #include 
>> -#include 
>> -#include 
>> +#include 
>>
>> -#include 
>> -#include 
>> +#include 
>>  #include 
>> +#include 
>>
>>  #define THS7303_CHANNEL_11
>>  #define THS7303_CHANNEL_22
>>  #define THS7303_CHANNEL_33
>>
>> +struct ths7303_state {
>> + struct v4l2_subdev  sd;
>> + struct ths7303_platform_datapdata;
>> + struct v4l2_bt_timings  bt;
>> + int std_id;
>> + int stream_on;
>> + int driver_data;
>> +};
>> +
>>  enum ths7303_filter_mode {
>>   THS7303_FILTER_MODE_480I_576I,
>>   THS7303_FILTER_MODE_480P_576P,
>> @@ -48,64 +58,84 @@ static int debug;
>>  module_param(debug, int, 0644);
>>  MODULE_PARM_DESC(debug, "Debug level 0-1");
>>
>> +static inline struct ths7303_state *to_state(struct v4l2_subdev *sd)
>> +{
>> + return container_of(sd, struct ths7303_state, sd);
>> +}
>> +
>> +static int ths7303_read(struct v4l2_subdev *sd, u8 reg)
>> +{
>> + struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> + return i2c_smbus_read_byte_data(client, reg);
>> +}
>> +
>> +static int ths7303_write(struct v4l2_subdev *sd, u8 reg, u8 val)
>> +{
>> + struct i2c_client *client = v4l2_get_subdevdata(sd);
>> + int ret;
>> + int i;
>> +
>> + for (i = 0; i < 3; i++) {
>> + ret = i2c_smbus_write_byte_data(client, reg, val);
>> + if (ret == 0)
>> + return 0;
>> + }
>> + return ret;
>> +}
>> +
>>  /* following function is used to set ths7303 */
>>  int ths7303_setval(struct v4l2_subdev *sd, enum ths7303_filter_mode mode)
>>  {
>> - u8 input_bias_chroma = 3;
>> - u8 input_bias_luma = 3;
>> - int disable = 0;
>> - int err = 0;
>> - u8 val = 0;
>> - u8 temp;
>> -
>>   struct i2c_client *client = v4l2_get_subdevdata(sd);
>> + struct ths7303_state *state = to_state(sd);
>> + struct ths7303_platform_data *pdata = >pdata;
>> + u8 val, sel = 0;
>> + int err, disable = 0;
>>
>>   if (!client)
>>   return -EINVAL;
>>
>>   switch (mode) {
>>   case THS7303_FILTER_MODE_1080P:
>> - val = (3 

[PATCH 3/7] staging/ozwpan: Fix sparse warning Using plain integer as NULL pointer

2013-02-14 Thread Peter Huewe
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing the offending 0s with NULL.

Signed-off-by: Peter Huewe 
---
 drivers/staging/ozwpan/ozeltbuf.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/ozwpan/ozeltbuf.c 
b/drivers/staging/ozwpan/ozeltbuf.c
index 988f522..4c81f28 100644
--- a/drivers/staging/ozwpan/ozeltbuf.c
+++ b/drivers/staging/ozwpan/ozeltbuf.c
@@ -64,7 +64,7 @@ void oz_elt_buf_term(struct oz_elt_buf *buf)
  */
 struct oz_elt_info *oz_elt_info_alloc(struct oz_elt_buf *buf)
 {
-   struct oz_elt_info *ei = 0;
+   struct oz_elt_info *ei = NULL;
spin_lock_bh(>lock);
if (buf->free_elts && buf->elt_pool) {
ei = container_of(buf->elt_pool, struct oz_elt_info, link);
@@ -82,9 +82,9 @@ struct oz_elt_info *oz_elt_info_alloc(struct oz_elt_buf *buf)
if (ei) {
ei->flags = 0;
ei->app_id = 0;
-   ei->callback = 0;
+   ei->callback = NULL;
ei->context = 0;
-   ei->stream = 0;
+   ei->stream = NULL;
ei->magic = OZ_ELT_INFO_MAGIC_USED;
INIT_LIST_HEAD(>link);
INIT_LIST_HEAD(>link_order);
@@ -135,7 +135,7 @@ int oz_elt_stream_create(struct oz_elt_buf *buf, u8 id, int 
max_buf_count)
oz_trace("oz_elt_stream_create(0x%x)\n", id);
 
st = kzalloc(sizeof(struct oz_elt_stream), GFP_ATOMIC | __GFP_ZERO);
-   if (st == 0)
+   if (st == NULL)
return -ENOMEM;
atomic_set(>ref_count, 1);
st->id = id;
@@ -161,7 +161,7 @@ int oz_elt_stream_delete(struct oz_elt_buf *buf, u8 id)
list_del(e);
break;
}
-   st = 0;
+   st = NULL;
}
if (!st) {
spin_unlock_bh(>lock);
@@ -208,7 +208,7 @@ void oz_elt_stream_put(struct oz_elt_stream *st)
 int oz_queue_elt_info(struct oz_elt_buf *buf, u8 isoc, u8 id,
struct oz_elt_info *ei)
 {
-   struct oz_elt_stream *st = 0;
+   struct oz_elt_stream *st = NULL;
struct list_head *e;
if (id) {
list_for_each(e, >stream_list) {
@@ -297,7 +297,7 @@ int oz_select_elts_for_tx(struct oz_elt_buf *buf, u8 isoc, 
unsigned *len,
"Stream down: %d  %d\n",
ei->stream->buf_count, ei->length);
oz_elt_stream_put(ei->stream);
-   ei->stream = 0;
+   ei->stream = NULL;
}
INIT_LIST_HEAD(>link_order);
list_add_tail(>link, list);
@@ -319,7 +319,7 @@ int oz_are_elts_available(struct oz_elt_buf *buf)
  */
 void oz_trim_elt_pool(struct oz_elt_buf *buf)
 {
-   struct list_head *free = 0;
+   struct list_head *free = NULL;
struct list_head *e;
spin_lock_bh(>lock);
while (buf->free_elts > buf->max_free_elts) {
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 4/7] staging/ozwpan: Fix sparse warning Using plain integer as NULL pointer

2013-02-14 Thread Peter Huewe
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing the offending 0s with NULL.

Signed-off-by: Peter Huewe 
---
 drivers/staging/ozwpan/ozproto.c |   78 +++---
 1 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/ozwpan/ozproto.c b/drivers/staging/ozwpan/ozproto.c
index e00a539..31857ab 100644
--- a/drivers/staging/ozwpan/ozproto.c
+++ b/drivers/staging/ozwpan/ozproto.c
@@ -98,7 +98,7 @@ static void oz_send_conn_rsp(struct oz_pd *pd, u8 status)
int sz = sizeof(struct oz_hdr) + sizeof(struct oz_elt) +
sizeof(struct oz_elt_connect_rsp);
skb = alloc_skb(sz + OZ_ALLOCATED_SPACE(dev), GFP_ATOMIC);
-   if (skb == 0)
+   if (skb == NULL)
return;
skb_reserve(skb, LL_RESERVED_SPACE(dev));
skb_reset_network_header(skb);
@@ -116,7 +116,7 @@ static void oz_send_conn_rsp(struct oz_pd *pd, u8 status)
oz_hdr->control = (OZ_PROTOCOL_VERSIONpkt_num);
-   oz_event_log(OZ_EVT_CONNECT_RSP, 0, 0, 0, 0);
+   oz_event_log(OZ_EVT_CONNECT_RSP, 0, 0, NULL, 0);
elt->type = OZ_ELT_CONNECT_RSP;
elt->length = sizeof(struct oz_elt_connect_rsp);
memset(body, 0, sizeof(struct oz_elt_connect_rsp));
@@ -179,17 +179,17 @@ static struct oz_pd *oz_connect_req(struct oz_pd *cur_pd, 
struct oz_elt *elt,
u8 rsp_status = OZ_STATUS_SUCCESS;
u8 stop_needed = 0;
u16 new_apps = g_apps;
-   struct net_device *old_net_dev = 0;
-   struct oz_pd *free_pd = 0;
+   struct net_device *old_net_dev = NULL;
+   struct oz_pd *free_pd = NULL;
if (cur_pd) {
pd = cur_pd;
spin_lock_bh(_polling_lock);
} else {
-   struct oz_pd *pd2 = 0;
+   struct oz_pd *pd2 = NULL;
struct list_head *e;
pd = oz_pd_alloc(pd_addr);
-   if (pd == 0)
-   return 0;
+   if (pd == NULL)
+   return NULL;
pd->last_rx_time_j = jiffies;
spin_lock_bh(_polling_lock);
list_for_each(e, _pd_list) {
@@ -203,9 +203,9 @@ static struct oz_pd *oz_connect_req(struct oz_pd *cur_pd, 
struct oz_elt *elt,
if (pd != pd2)
list_add_tail(>link, _pd_list);
}
-   if (pd == 0) {
+   if (pd == NULL) {
spin_unlock_bh(_polling_lock);
-   return 0;
+   return NULL;
}
if (pd->net_dev != net_dev) {
old_net_dev = pd->net_dev;
@@ -294,7 +294,7 @@ done:
if (stop_needed)
oz_pd_stop(pd);
oz_pd_put(pd);
-   pd = 0;
+   pd = NULL;
}
if (old_net_dev)
dev_put(old_net_dev);
@@ -340,14 +340,14 @@ static void oz_rx_frame(struct sk_buff *skb)
u8 *src_addr;
struct oz_elt *elt;
int length;
-   struct oz_pd *pd = 0;
+   struct oz_pd *pd = NULL;
struct oz_hdr *oz_hdr = (struct oz_hdr *)skb_network_header(skb);
int dup = 0;
u32 pkt_num;
 
oz_event_log(OZ_EVT_RX_PROCESS, 0,
(((u16)oz_hdr->control)<<8)|oz_hdr->last_pkt_num,
-   0, oz_hdr->pkt_num);
+   NULL, oz_hdr->pkt_num);
oz_trace2(OZ_TRACE_RX_FRAMES,
"RX frame PN=0x%x LPN=0x%x control=0x%x\n",
oz_hdr->pkt_num, oz_hdr->last_pkt_num, oz_hdr->control);
@@ -402,7 +402,7 @@ static void oz_rx_frame(struct sk_buff *skb)
break;
switch (elt->type) {
case OZ_ELT_CONNECT_REQ:
-   oz_event_log(OZ_EVT_CONNECT_REQ, 0, 0, 0, 0);
+   oz_event_log(OZ_EVT_CONNECT_REQ, 0, 0, NULL, 0);
oz_trace("RX: OZ_ELT_CONNECT_REQ\n");
pd = oz_connect_req(pd, elt, src_addr, skb->dev);
break;
@@ -456,7 +456,7 @@ done:
  */
 void oz_protocol_term(void)
 {
-   struct list_head *chain = 0;
+   struct list_head *chain = NULL;
del_timer_sync(_timer);
/* Walk the list of bindings and remove each one.
 */
@@ -487,7 +487,7 @@ void oz_protocol_term(void)
spin_lock_bh(_polling_lock);
}
chain = g_timer_pool;
-   g_timer_pool = 0;
+   g_timer_pool = NULL;
spin_unlock_bh(_polling_lock);
while (chain) {
struct oz_timer *t = container_of(chain, struct oz_timer, link);
@@ -534,25 +534,25 @@ static void oz_protocol_timer(unsigned long arg)
/* This happens if we remove the current timer but can't stop
 * the timer from firing. In this case just get out.
 */
-   oz_event_log(OZ_EVT_TIMER, 0, 0, 0, 0);
+  

[PATCH 7/7] staging/ozwpan: Fix sparse warning Using plain integer as NULL pointer

2013-02-14 Thread Peter Huewe
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing the offending 0s with NULL.

Signed-off-by: Peter Huewe 
---
 drivers/staging/ozwpan/ozhcd.c |  135 
 1 files changed, 68 insertions(+), 67 deletions(-)

diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c
index 9154f33..b48663e 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -248,7 +248,7 @@ static int oz_get_port_from_addr(struct oz_hcd *ozhcd, u8 
bus_addr)
  */
 static struct oz_urb_link *oz_alloc_urb_link(void)
 {
-   struct oz_urb_link *urbl = 0;
+   struct oz_urb_link *urbl = NULL;
unsigned long irq_state;
spin_lock_irqsave(_link_lock, irq_state);
if (g_link_pool) {
@@ -257,7 +257,7 @@ static struct oz_urb_link *oz_alloc_urb_link(void)
--g_link_pool_size;
}
spin_unlock_irqrestore(_link_lock, irq_state);
-   if (urbl == 0)
+   if (urbl == NULL)
urbl = kmalloc(sizeof(struct oz_urb_link), GFP_ATOMIC);
return urbl;
 }
@@ -274,7 +274,7 @@ static void oz_free_urb_link(struct oz_urb_link *urbl)
if (g_link_pool_size < OZ_MAX_LINK_POOL_SIZE) {
urbl->link.next = g_link_pool;
g_link_pool = >link;
-   urbl = 0;
+   urbl = NULL;
g_link_pool_size++;
}
spin_unlock_irqrestore(_link_lock, irq_state);
@@ -291,7 +291,7 @@ static void oz_empty_link_pool(void)
unsigned long irq_state;
spin_lock_irqsave(_link_lock, irq_state);
e = g_link_pool;
-   g_link_pool = 0;
+   g_link_pool = NULL;
g_link_pool_size = 0;
spin_unlock_irqrestore(_link_lock, irq_state);
while (e) {
@@ -337,7 +337,7 @@ struct oz_urb_link *oz_uncancel_urb(struct oz_hcd *ozhcd, 
struct urb *urb)
return urbl;
}
}
-   return 0;
+   return NULL;
 }
 
/*--
  * This is called when we have finished processing an urb. It unlinks it from
@@ -349,13 +349,13 @@ static void oz_complete_urb(struct usb_hcd *hcd, struct 
urb *urb,
 {
struct oz_hcd *ozhcd = oz_hcd_private(hcd);
unsigned long irq_state;
-   struct oz_urb_link *cancel_urbl = 0;
+   struct oz_urb_link *cancel_urbl = NULL;
spin_lock_irqsave(_tasklet_lock, irq_state);
usb_hcd_unlink_urb_from_ep(hcd, urb);
/* Clear hcpriv which will prevent it being put in the cancel list
 * in the event that an attempt is made to cancel it.
 */
-   urb->hcpriv = 0;
+   urb->hcpriv = NULL;
/* Walk the cancel list in case the urb is already sitting there.
 * Since we process the cancel list in a tasklet rather than in
 * the dequeue function this could happen.
@@ -507,7 +507,7 @@ static int oz_enqueue_ep_urb(struct oz_port *port, u8 
ep_addr, int in_dir,
ep->last_jiffies = jiffies;
ep->credit = 0;
oz_event_log(OZ_EVT_EP_CREDIT, ep->ep_num,
-   0, 0, ep->credit);
+   0, NULL, ep->credit);
}
} else {
err = -EPIPE;
@@ -525,7 +525,7 @@ static int oz_enqueue_ep_urb(struct oz_port *port, u8 
ep_addr, int in_dir,
 static int oz_dequeue_ep_urb(struct oz_port *port, u8 ep_addr, int in_dir,
struct urb *urb)
 {
-   struct oz_urb_link *urbl = 0;
+   struct oz_urb_link *urbl = NULL;
struct oz_endpoint *ep;
spin_lock_bh(>ozhcd->hcd_lock);
if (in_dir)
@@ -540,7 +540,7 @@ static int oz_dequeue_ep_urb(struct oz_port *port, u8 
ep_addr, int in_dir,
list_del_init(e);
break;
}
-   urbl = 0;
+   urbl = NULL;
}
}
spin_unlock_bh(>ozhcd->hcd_lock);
@@ -556,8 +556,8 @@ static struct urb *oz_find_urb_by_id(struct oz_port *port, 
int ep_ix,
u8 req_id)
 {
struct oz_hcd *ozhcd = port->ozhcd;
-   struct urb *urb = 0;
-   struct oz_urb_link *urbl = 0;
+   struct urb *urb = NULL;
+   struct oz_urb_link *urbl = NULL;
struct oz_endpoint *ep;
 
spin_lock_bh(>hcd_lock);
@@ -630,13 +630,13 @@ static inline void oz_hcd_put(struct oz_hcd *ozhcd)
 void *oz_hcd_pd_arrived(void *hpd)
 {
int i;
-   void *hport = 0;
-   struct oz_hcd *ozhcd = 0;
+   void *hport = NULL;
+   struct oz_hcd *ozhcd = NULL;
struct oz_endpoint *ep;
oz_trace("oz_hcd_pd_arrived()\n");
ozhcd = oz_hcd_claim();
-   if (ozhcd == 0)
-   return 0;
+   if 

[PATCH 2/7] staging/ozwpan: Fix sparse warning Using plain integer as NULL pointer

2013-02-14 Thread Peter Huewe
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing the offending 0s with NULL.

Signed-off-by: Peter Huewe 
---
 drivers/staging/ozwpan/ozusbsvc1.c |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/ozwpan/ozusbsvc1.c 
b/drivers/staging/ozwpan/ozusbsvc1.c
index 66bd576..ea4a238b 100644
--- a/drivers/staging/ozwpan/ozusbsvc1.c
+++ b/drivers/staging/ozwpan/ozusbsvc1.c
@@ -71,7 +71,7 @@ int oz_usb_get_desc_req(void *hpd, u8 req_id, u8 req_type, u8 
desc_type,
oz_trace("len = 0x%x\n", len);
if (len > 200)
len = 200;
-   if (ei == 0)
+   if (ei == NULL)
return -1;
elt = (struct oz_elt *)ei->data;
elt->length = sizeof(struct oz_get_desc_req);
@@ -97,7 +97,7 @@ static int oz_usb_set_config_req(void *hpd, u8 req_id, u8 
index)
struct oz_elt_buf *eb = >elt_buff;
struct oz_elt_info *ei = oz_elt_info_alloc(>elt_buff);
struct oz_set_config_req *body;
-   if (ei == 0)
+   if (ei == NULL)
return -1;
elt = (struct oz_elt *)ei->data;
elt->length = sizeof(struct oz_set_config_req);
@@ -118,7 +118,7 @@ static int oz_usb_set_interface_req(void *hpd, u8 req_id, 
u8 index, u8 alt)
struct oz_elt_buf *eb = >elt_buff;
struct oz_elt_info *ei = oz_elt_info_alloc(>elt_buff);
struct oz_set_interface_req *body;
-   if (ei == 0)
+   if (ei == NULL)
return -1;
elt = (struct oz_elt *)ei->data;
elt->length = sizeof(struct oz_set_interface_req);
@@ -141,7 +141,7 @@ static int oz_usb_set_clear_feature_req(void *hpd, u8 
req_id, u8 type,
struct oz_elt_buf *eb = >elt_buff;
struct oz_elt_info *ei = oz_elt_info_alloc(>elt_buff);
struct oz_feature_req *body;
-   if (ei == 0)
+   if (ei == NULL)
return -1;
elt = (struct oz_elt *)ei->data;
elt->length = sizeof(struct oz_feature_req);
@@ -165,7 +165,7 @@ static int oz_usb_vendor_class_req(void *hpd, u8 req_id, u8 
req_type,
struct oz_elt_buf *eb = >elt_buff;
struct oz_elt_info *ei = oz_elt_info_alloc(>elt_buff);
struct oz_vendor_class_req *body;
-   if (ei == 0)
+   if (ei == NULL)
return -1;
elt = (struct oz_elt *)ei->data;
elt->length = sizeof(struct oz_vendor_class_req) - 1 + data_len;
@@ -264,7 +264,7 @@ int oz_usb_send_isoc(void *hpd, u8 ep_num, struct urb *urb)
int unit_count;
int unit_size;
int rem;
-   if (ei == 0)
+   if (ei == NULL)
return -1;
rem = MAX_ISOC_FIXED_DATA;
elt = (struct oz_elt *)ei->data;
@@ -359,7 +359,7 @@ void oz_usb_rx(struct oz_pd *pd, struct oz_elt *elt)
if (usb_ctx)
oz_usb_get(usb_ctx);
spin_unlock_bh(>app_lock[OZ_APPID_USB-1]);
-   if (usb_ctx == 0)
+   if (usb_ctx == NULL)
return; /* Context has gone so nothing to do. */
if (usb_ctx->stopped)
goto done;
@@ -391,14 +391,14 @@ void oz_usb_rx(struct oz_pd *pd, struct oz_elt *elt)
struct oz_set_config_rsp *body =
(struct oz_set_config_rsp *)usb_hdr;
oz_hcd_control_cnf(usb_ctx->hport, body->req_id,
-   body->rcode, 0, 0);
+   body->rcode, NULL, 0);
}
break;
case OZ_SET_INTERFACE_RSP: {
struct oz_set_interface_rsp *body =
(struct oz_set_interface_rsp *)usb_hdr;
oz_hcd_control_cnf(usb_ctx->hport,
-   body->req_id, body->rcode, 0, 0);
+   body->req_id, body->rcode, NULL, 0);
}
break;
case OZ_VENDOR_CLASS_RSP: {
@@ -427,7 +427,7 @@ void oz_usb_farewell(struct oz_pd *pd, u8 ep_num, u8 *data, 
u8 len)
if (usb_ctx)
oz_usb_get(usb_ctx);
spin_unlock_bh(>app_lock[OZ_APPID_USB-1]);
-   if (usb_ctx == 0)
+   if (usb_ctx == NULL)
return; /* Context has gone so nothing to do. */
if (!usb_ctx->stopped) {
oz_trace("Farewell indicated ep = 0x%x\n", ep_num);
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 6/7] staging/ozwpan: Fix sparse warning Using plain integer as NULL pointer

2013-02-14 Thread Peter Huewe
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing the offending 0s with NULL.

Signed-off-by: Peter Huewe 
---
 drivers/staging/ozwpan/ozusbsvc.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/ozwpan/ozusbsvc.c 
b/drivers/staging/ozwpan/ozusbsvc.c
index 8fa7f25..e12343e 100644
--- a/drivers/staging/ozwpan/ozusbsvc.c
+++ b/drivers/staging/ozwpan/ozusbsvc.c
@@ -34,7 +34,7 @@
  */
 int oz_usb_init(void)
 {
-   oz_event_log(OZ_EVT_SERVICE, 1, OZ_APPID_USB, 0, 0);
+   oz_event_log(OZ_EVT_SERVICE, 1, OZ_APPID_USB, NULL, 0);
return oz_hcd_init();
 }
 
/*--
@@ -43,7 +43,7 @@ int oz_usb_init(void)
  */
 void oz_usb_term(void)
 {
-   oz_event_log(OZ_EVT_SERVICE, 2, OZ_APPID_USB, 0, 0);
+   oz_event_log(OZ_EVT_SERVICE, 2, OZ_APPID_USB, NULL, 0);
oz_hcd_term();
 }
 
/*--
@@ -54,8 +54,8 @@ int oz_usb_start(struct oz_pd *pd, int resume)
 {
int rc = 0;
struct oz_usb_ctx *usb_ctx;
-   struct oz_usb_ctx *old_ctx = 0;
-   oz_event_log(OZ_EVT_SERVICE, 3, OZ_APPID_USB, 0, resume);
+   struct oz_usb_ctx *old_ctx = NULL;
+   oz_event_log(OZ_EVT_SERVICE, 3, OZ_APPID_USB, NULL, resume);
if (resume) {
oz_trace("USB service resumed.\n");
return 0;
@@ -65,7 +65,7 @@ int oz_usb_start(struct oz_pd *pd, int resume)
 * has a USB context then we will destroy it.
 */
usb_ctx = kzalloc(sizeof(struct oz_usb_ctx), GFP_ATOMIC);
-   if (usb_ctx == 0)
+   if (usb_ctx == NULL)
return -ENOMEM;
atomic_set(_ctx->ref_count, 1);
usb_ctx->pd = pd;
@@ -76,7 +76,7 @@ int oz_usb_start(struct oz_pd *pd, int resume)
 */
spin_lock_bh(>app_lock[OZ_APPID_USB-1]);
old_ctx = pd->app_ctx[OZ_APPID_USB-1];
-   if (old_ctx == 0)
+   if (old_ctx == NULL)
pd->app_ctx[OZ_APPID_USB-1] = usb_ctx;
oz_usb_get(pd->app_ctx[OZ_APPID_USB-1]);
spin_unlock_bh(>app_lock[OZ_APPID_USB-1]);
@@ -98,10 +98,10 @@ int oz_usb_start(struct oz_pd *pd, int resume)
oz_hcd_pd_reset(usb_ctx, usb_ctx->hport);
} else {
usb_ctx->hport = oz_hcd_pd_arrived(usb_ctx);
-   if (usb_ctx->hport == 0) {
+   if (usb_ctx->hport == NULL) {
oz_trace("USB hub returned null port.\n");
spin_lock_bh(>app_lock[OZ_APPID_USB-1]);
-   pd->app_ctx[OZ_APPID_USB-1] = 0;
+   pd->app_ctx[OZ_APPID_USB-1] = NULL;
spin_unlock_bh(>app_lock[OZ_APPID_USB-1]);
oz_usb_put(usb_ctx);
rc = -1;
@@ -117,14 +117,14 @@ int oz_usb_start(struct oz_pd *pd, int resume)
 void oz_usb_stop(struct oz_pd *pd, int pause)
 {
struct oz_usb_ctx *usb_ctx;
-   oz_event_log(OZ_EVT_SERVICE, 4, OZ_APPID_USB, 0, pause);
+   oz_event_log(OZ_EVT_SERVICE, 4, OZ_APPID_USB, NULL, pause);
if (pause) {
oz_trace("USB service paused.\n");
return;
}
spin_lock_bh(>app_lock[OZ_APPID_USB-1]);
usb_ctx = (struct oz_usb_ctx *)pd->app_ctx[OZ_APPID_USB-1];
-   pd->app_ctx[OZ_APPID_USB-1] = 0;
+   pd->app_ctx[OZ_APPID_USB-1] = NULL;
spin_unlock_bh(>app_lock[OZ_APPID_USB-1]);
if (usb_ctx) {
unsigned long tout = jiffies + HZ;
@@ -182,7 +182,7 @@ int oz_usb_heartbeat(struct oz_pd *pd)
if (usb_ctx)
oz_usb_get(usb_ctx);
spin_unlock_bh(>app_lock[OZ_APPID_USB-1]);
-   if (usb_ctx == 0)
+   if (usb_ctx == NULL)
return rc;
if (usb_ctx->stopped)
goto done;
-- 
1.7.8.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/7] staging/ozwpan: Fix sparse warning Using plain integer as NULL pointer

2013-02-14 Thread Peter Huewe
This patch fixes the warning "Using plain integer as NULL pointer",
generated by sparse, by replacing the offending 0s with NULL.

Signed-off-by: Peter Huewe 
---
I split up this patch series on a per file basis so that review is easier.

 drivers/staging/ozwpan/ozpd.c |   68 
 1 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/ozwpan/ozpd.c b/drivers/staging/ozwpan/ozpd.c
index 118a4db..191b63e 100644
--- a/drivers/staging/ozwpan/ozpd.c
+++ b/drivers/staging/ozwpan/ozpd.c
@@ -61,8 +61,8 @@ static struct oz_app_if g_app_if[OZ_APPID_MAX] = {
oz_def_app_start,
oz_def_app_stop,
oz_def_app_rx,
-   0,
-   0,
+   NULL,
+   NULL,
OZ_APPID_UNUSED1},
 
{oz_def_app_init,
@@ -70,8 +70,8 @@ static struct oz_app_if g_app_if[OZ_APPID_MAX] = {
oz_def_app_start,
oz_def_app_stop,
oz_def_app_rx,
-   0,
-   0,
+   NULL,
+   NULL,
OZ_APPID_UNUSED2},
 
{oz_cdev_init,
@@ -79,8 +79,8 @@ static struct oz_app_if g_app_if[OZ_APPID_MAX] = {
oz_cdev_start,
oz_cdev_stop,
oz_cdev_rx,
-   0,
-   0,
+   NULL,
+   NULL,
OZ_APPID_SERIAL},
 };
 
/*--
@@ -121,7 +121,7 @@ static void oz_def_app_rx(struct oz_pd *pd, struct oz_elt 
*elt)
 void oz_pd_set_state(struct oz_pd *pd, unsigned state)
 {
pd->state = state;
-   oz_event_log(OZ_EVT_PD_STATE, 0, 0, 0, state);
+   oz_event_log(OZ_EVT_PD_STATE, 0, 0, NULL, state);
 #ifdef WANT_TRACE
switch (state) {
case OZ_PD_S_IDLE:
@@ -171,7 +171,7 @@ struct oz_pd *oz_pd_alloc(u8 *mac_addr)
memcpy(pd->mac_addr, mac_addr, ETH_ALEN);
if (0 != oz_elt_buf_init(>elt_buff)) {
kfree(pd);
-   pd = 0;
+   pd = NULL;
}
spin_lock_init(>tx_frame_lock);
INIT_LIST_HEAD(>tx_queue);
@@ -355,7 +355,7 @@ int oz_pd_sleep(struct oz_pd *pd)
  */
 static struct oz_tx_frame *oz_tx_frame_alloc(struct oz_pd *pd)
 {
-   struct oz_tx_frame *f = 0;
+   struct oz_tx_frame *f = NULL;
spin_lock_bh(>tx_frame_lock);
if (pd->tx_pool) {
f = container_of(pd->tx_pool, struct oz_tx_frame, link);
@@ -363,7 +363,7 @@ static struct oz_tx_frame *oz_tx_frame_alloc(struct oz_pd 
*pd)
pd->tx_pool_count--;
}
spin_unlock_bh(>tx_frame_lock);
-   if (f == 0)
+   if (f == NULL)
f = kmalloc(sizeof(struct oz_tx_frame), GFP_ATOMIC);
if (f) {
f->total_size = sizeof(struct oz_hdr);
@@ -399,7 +399,7 @@ static void oz_tx_frame_free(struct oz_pd *pd, struct 
oz_tx_frame *f)
f->link.next = pd->tx_pool;
pd->tx_pool = >link;
pd->tx_pool_count++;
-   f = 0;
+   f = NULL;
}
spin_unlock_bh(>tx_frame_lock);
kfree(f);
@@ -433,7 +433,7 @@ int oz_prepare_frame(struct oz_pd *pd, int empty)
if (!empty && !oz_are_elts_available(>elt_buff))
return -1;
f = oz_tx_frame_alloc(pd);
-   if (f == 0)
+   if (f == NULL)
return -1;
f->skb = NULL;
f->hdr.control =
@@ -455,7 +455,7 @@ int oz_prepare_frame(struct oz_pd *pd, int empty)
  */
 static struct sk_buff *oz_build_frame(struct oz_pd *pd, struct oz_tx_frame *f)
 {
-   struct sk_buff *skb = 0;
+   struct sk_buff *skb = NULL;
struct net_device *dev = pd->net_dev;
struct oz_hdr *oz_hdr;
struct oz_elt *elt;
@@ -464,8 +464,8 @@ static struct sk_buff *oz_build_frame(struct oz_pd *pd, 
struct oz_tx_frame *f)
 * as the space we need.
 */
skb = alloc_skb(f->total_size + OZ_ALLOCATED_SPACE(dev), GFP_ATOMIC);
-   if (skb == 0)
-   return 0;
+   if (skb == NULL)
+   return NULL;
/* Reserve the head room for lower layers.
 */
skb_reserve(skb, LL_RESERVED_SPACE(dev));
@@ -492,7 +492,7 @@ static struct sk_buff *oz_build_frame(struct oz_pd *pd, 
struct oz_tx_frame *f)
return skb;
 fail:
kfree_skb(skb);
-   return 0;
+   return NULL;
 }
 
/*--
  * Context: softirq or process
@@ -544,7 +544,7 @@ static int oz_send_next_queued_frame(struct oz_pd *pd, int 
more_data)
if (dev_queue_xmit(skb) < 0) {
oz_trace2(OZ_TRACE_TX_FRAMES,
"Dropping ISOC Frame\n");
-   oz_event_log(OZ_EVT_TX_ISOC_DROP, 0, 0, 0, 0);
+   oz_event_log(OZ_EVT_TX_ISOC_DROP, 0, 0, NULL, 
0);
return -1;
}
  

Re: [PATCH 1/3] posix timers: Allocate timer id per process

2013-02-14 Thread Pavel Emelyanov
On 02/15/2013 12:13 AM, Sasha Levin wrote:
> On Thu, Feb 14, 2013 at 11:19 AM, Pavel Emelyanov  wrote:
>> From: Stanislav Kinsbursky 
>>
>> Patch replaces global idr with global hash table for posix timers and
>> makes timer ids unique not globally, but per process. Next free timer id is
>> type of integer and stored on signal struct (posix_timer_id). If free timer
>> id reaches negative value on timer creation, it will be dropped to zero and
>> -EAGAIN will be returned to user.
>>
>> Hash table has 512 slots.
>> Key is constructed as follows:
>> key = hash_32(hash_32(current->signal) ^ posix_timer_id));
>>
>> Note: with this patch, id, returned to user, is not the minimal free
>> amymore. It means, that id, returned to user space in loop, listed below, 
>> will
>> be increasing on each iteration till INT_MAX and then dropped to zero:
>>
>> while(1) {
>> id = timer_create(...);
>> timer_delete(id);
>> }
>>
>> Signed-off-by: Stanislav Kinsbursky 
>> Signed-off-by: Pavel Emelyanov 
> 
> Hi Pavel,
> 
> Why not use linux/hashtable.h?

Simply because this patch was just picked from the previous discussions
as is :) I will tune it to use hashtable.h in the next iteration.

> 
> Thanks,
> Sasha
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 1/4] ARM: Exynos5250: Enabling ehci-s5p driver

2013-02-14 Thread Vivek Gautam
On Sat, Feb 9, 2013 at 4:05 AM, Kukjin Kim  wrote:
> Vivek Gautam wrote:
>>
>> Adding EHCI device tree node for Exynos5250 along with
>> the device base adress and gpio line for vbus.
>>
>> Signed-off-by: Vivek Gautam 
>> Acked-by: Jingoo Han 
>> Acked-by: Grant Likely 
>> ---
>>
>> Changes from v4:
>>  - Added gpio line for VBUS of USB2.0 on snow board.
>>
>>  .../devicetree/bindings/usb/exynos-usb.txt |   25
>> 
>>  arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +++
>>  arch/arm/boot/dts/exynos5250-snow.dts  |4 +++
>>  arch/arm/boot/dts/exynos5250.dtsi  |6 
>>  4 files changed, 39 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/usb/exynos-
>> usb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> new file mode 100644
>> index 000..e8bbb47
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> @@ -0,0 +1,25 @@
>> +Samsung Exynos SoC USB controller
>> +
>> +The USB devices interface with USB controllers on Exynos SOCs.
>> +The device node has following properties.
>> +
>> +EHCI
>> +Required properties:
>> + - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
>> +   EHCI controller in host mode.
>> + - reg: physical base address of the controller and length of memory
>> mapped
>> +   region.
>> + - interrupts: interrupt number to the cpu.
>> +
>> +Optional properties:
>> + - samsung,vbus-gpio:  if present, specifies the GPIO that
>> +   needs to be pulled up for the bus to be powered.
>> +
>> +Example:
>> +
>> + usb@1211 {
>> + compatible = "samsung,exynos4210-ehci";
>> + reg = <0x1211 0x100>;
>> + interrupts = <0 71 0>;
>> + samsung,vbus-gpio = < 6 1 3 3>;
>> + };
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index 942d576..7363e14 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -204,4 +204,8 @@
>>   samsung,mfc-r = <0x4300 0x80>;
>>   samsung,mfc-l = <0x5100 0x80>;
>>   };
>> +
>> + usb@1211 {
>> + samsung,vbus-gpio = < 6 1 3 3>;
>> + };
>>  };
>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
>> b/arch/arm/boot/dts/exynos5250-snow.dts
>> index 17dd951..47b6b84 100644
>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>> @@ -40,4 +40,8 @@
>>   < 5 2 3 0>, < 6 2 3 0>;
>>   };
>>   };
>> +
>> + usb@1211 {
>> + samsung,vbus-gpio = < 1 1 3 3>;
>> + };
>>  };
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 30485de..2cbe53e 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -275,6 +275,12 @@
>>   #size-cells = <0>;
>>   };
>>
>> + usb@1211 {
>> + compatible = "samsung,exynos4210-ehci";
>> + reg = <0x1211 0x100>;
>> + interrupts = <0 71 0>;
>> + };
>> +
>>   amba {
>>   #address-cells = <1>;
>>   #size-cells = <1>;
>> --
>> 1.7.6.5
>
> Looks good to me and applied this and "[PATCH v3 2/4] ARM: Exynos5250:
> Enabling ohci-exynos driver" in Samsung tree.
>
> Note, I think, you need to implement to use pinctrl for this instead of old
> gpio bindings next time, probably after release v3.9-rc1.
>

Sure, will add the necessary pinctrl support replacing the old gpio bindings,
and post the same asap. :-)

> Ah, one more, please use subject lines appropriate like others, "ARM: dts:
> ".
>

Sorry, for misleading subject line, will keep commit titles
aligned-with in future,

> Thanks.
>
> - Kukjin
>


-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] [media] davinci: do not include mach/hardware.h

2013-02-14 Thread Prabhakar Lad
Hi Arnd,

Thanks for the patch.

On Fri, Feb 15, 2013 at 4:17 AM, Arnd Bergmann  wrote:
> It is now possible to build the davinci vpss code
> on multiplatform kernels, which causes a problem
> since the driver tries to incude the davinci
> platform specific mach/hardware.h file. Fortunately
> that file is not required at all in the driver,
> so we can simply remove the #include statement.
>
> Without this patch, building allyesconfig results in:
>
> drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No 
> such file or directory
> compilation terminated.
>
> Signed-off-by: Arnd Bergmann 
> Cc: Mauro Carvalho Chehab 
> Cc: "Lad, Prabhakar" 
> Cc: Tony Lindgren 

Acked-by: Lad, Prabhakar 

Regards,
--Prabhakar

> ---
>  drivers/media/platform/davinci/vpss.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/davinci/vpss.c 
> b/drivers/media/platform/davinci/vpss.c
> index 494d322..a19c552 100644
> --- a/drivers/media/platform/davinci/vpss.c
> +++ b/drivers/media/platform/davinci/vpss.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>
>  MODULE_LICENSE("GPL");
> --
> 1.8.1.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


linux-next: manual merge of the driver-core tree with the tree

2013-02-14 Thread Stephen Rothwell
Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
drivers/net/wireless/rtlwifi/Kconfig between commit 06e7cda3ce30
("rtlwifi: Rework Kconfig") from the wireless-next tree and commit
6cba014857f4 ("drivers/net/wireless/rtlwifi: remove depends on
CONFIG_EXPERIMENTAL") from the driver-core tree.

I fixed it up (the former is a superset of the latter, so I used that)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpOqf8UO7D2E.pgp
Description: PGP signature


Re: [PATCH 3/9] clk: sunxi: remove stale Makefile entry

2013-02-14 Thread Mike Turquette
Quoting Arnd Bergmann (2013-02-14 14:26:52)
> Patch 85a18198 "clk: sunxi: Use common of_clk_init() function"
> removed the clk-sunxi.c file but left the Makefile entry, which
> causes a build error in multi_v7_defconfig:
> 
> make[4]: *** No rule to make target `drivers/clk/clk-sunxi.o', needed by 
> `drivers/clk/built-in.o'.
> 
> The obvious fix is to remove the extraneous line from the
> Makefile.
> 

The fix is correct.  I can't rebase my branch since there is an existing
dependency with the tegra tree, so I have taken this patch as-is with
the addition of my SoB.

Thanks,
Mike

> Signed-off-by: Arnd Bergmann 
> Cc: Prashant Gaikwad 
> Cc: Maxime Ripard 
> Cc: Mike Turquette 
> ---
>  drivers/clk/Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index ce77077..be9392e 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -25,7 +25,6 @@ endif
>  obj-$(CONFIG_MACH_LOONGSON1)   += clk-ls1x.o
>  obj-$(CONFIG_ARCH_U8500)   += ux500/
>  obj-$(CONFIG_ARCH_VT8500)  += clk-vt8500.o
> -obj-$(CONFIG_ARCH_SUNXI)   += clk-sunxi.o
>  obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
>  obj-$(CONFIG_X86)  += x86/
>  obj-$(CONFIG_ARCH_TEGRA)   += tegra/
> -- 
> 1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/4] of/pci: Provide support for parsing PCI DT ranges property

2013-02-14 Thread Thomas Petazzoni
Hello,

On Thu, 14 Feb 2013 20:17:45 +0100, Thierry Reding wrote:
> On Thu, Feb 14, 2013 at 04:53:41PM +, Andrew Murray wrote:
> > Thierry,
> > 
> > If you don't have much bandwidth I'd be quite happy to take this on - this
> > would be beneficial for my eventual patchset. I can start by refactoring 
> > common
> > implementations of pci_process_bridge_OF_ranges or similar across the
> > architectures as per Grant's suggestion? I didn't do this when I first 
> > posted
> > the patch as I was concerned about the testing effort.
> 
> Absolutely! Since it was your patch in the first place you're just as
> well suited to do this if you want to and have the time.

And I'll be more than happy to test your patches in the context of the
Marvell PCIe driver.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


linux-next: build failure after merge of the xen-two tree

2013-02-14 Thread Stephen Rothwell
Hi Konrad,

After merging the xen-two tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/xen/xen-acpi-memhotplug.c: In function 'acpi_memory_get_device':
drivers/xen/xen-acpi-memhotplug.c:191:2: error: implicit declaration of 
function 'acpi_bus_add' [-Werror=implicit-function-declaration]
drivers/xen/xen-acpi-memhotplug.c: At top level:
drivers/xen/xen-acpi-memhotplug.c:417:3: warning: initialization from 
incompatible pointer type [enabled by default]
drivers/xen/xen-acpi-memhotplug.c:417:3: warning: (near initialization for 
'xen_acpi_memory_device_driver.ops.remove') [enabled by default]

Caused by commit 259f201cb7ea ("xen/acpi: ACPI memory hotplug").

drivers/xen/xen-acpi-cpuhotplug.c: In function 'acpi_processor_device_add':
drivers/xen/xen-acpi-cpuhotplug.c:254:2: error: implicit declaration of 
function 'acpi_bus_add' [-Werror=implicit-function-declaration]
drivers/xen/xen-acpi-cpuhotplug.c: At top level:
drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: initialization from 
incompatible pointer type [enabled by default]
drivers/xen/xen-acpi-cpuhotplug.c:425:3: warning: (near initialization for 
'xen_acpi_processor_driver.ops.remove') [enabled by default]

Caused by commit 181232c249f0 ("xen/acpi: ACPI cpu hotplug").

These commits interacted with commits 636458de36f1 ("ACPI: Remove the
arguments of acpi_bus_add() that are not used"), 0cd6ac52b333 ("ACPI:
Make acpi_bus_scan() and acpi_bus_add() take only one argument") and
b8bd759acd05 ("ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan()
instead") from the pm tree.

I have added this merge fix patch and can carry it as necessary (I did
*not* fix the warnings above):

From: Stephen Rothwell 
Date: Fri, 15 Feb 2013 15:37:27 +1100
Subject: [PATCH] xen/acpi: fix up for apci_bus_add api change

Signed-off-by: Stephen Rothwell 
---
 drivers/xen/xen-acpi-cpuhotplug.c | 2 +-
 drivers/xen/xen-acpi-memhotplug.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-acpi-cpuhotplug.c 
b/drivers/xen/xen-acpi-cpuhotplug.c
index 9eefbb0..0db4722 100644
--- a/drivers/xen/xen-acpi-cpuhotplug.c
+++ b/drivers/xen/xen-acpi-cpuhotplug.c
@@ -251,7 +251,7 @@ int acpi_processor_device_add(acpi_handle handle, struct 
acpi_device **device)
if (acpi_bus_get_device(phandle, ))
return -ENODEV;
 
-   if (acpi_bus_add(device, pdev, handle, ACPI_BUS_TYPE_PROCESSOR))
+   if (acpi_bus_scan(handle))
return -ENODEV;
 
return 0;
diff --git a/drivers/xen/xen-acpi-memhotplug.c 
b/drivers/xen/xen-acpi-memhotplug.c
index 678680c..164287b 100644
--- a/drivers/xen/xen-acpi-memhotplug.c
+++ b/drivers/xen/xen-acpi-memhotplug.c
@@ -188,7 +188,7 @@ acpi_memory_get_device(acpi_handle handle,
 * Now add the notified device.  This creates the acpi_device
 * and invokes .add function
 */
-   result = acpi_bus_add(, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
+   result = acpi_bus_scan(handle);
if (result) {
pr_warn(PREFIX "Cannot add acpi bus\n");
return -EINVAL;
-- 
1.8.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpqcMBGZ2VL5.pgp
Description: PGP signature


Re: [PATCH] Move console redirect to pid namespace

2013-02-14 Thread Eric W. Biederman
Corey Minyard  writes:

> On 02/13/2013 01:08 PM, Eric W. Biederman wrote:
>> Bruno Prémont  writes:
>>
>>> CCing containers list
>>>
>>> On Fri, 08 February 2013 miny...@acm.org wrote:
 From: Corey Minyard 

 The console redirect - ioctl(fd, TIOCCONS) - is not in a namespace,
 thus a container can do a redirect and grab all the I/O on the host
 and all container consoles.

 This change puts the redirect in the pid namespace.

 Signed-off-by: Corey Minyard 
 ---

 I'm pretty sure this patch is not correct, but I'm not quite sure the
 best way to fix this.  I'm not 100% sure that the pid namespace is the
 right place, but it seemed the most reasonable of all the choices.  The
 other obvious choice is the mount namespace, but it didn't seem as good
 a fit.
>>> With recent changes, tying it to init user namespace might even be
>>> better.
>> With recent changes this is tied to the initial user namespace.  So the
>> simple solution to this and so many other similiar security problems is
>> to run your container in a user namespace.
>>
>> The permission check currently is capable(CAP_SYS_ADMIN) which requires
>> the caller to have the CAP_SYS_ADMIN in the initial user namespace.
>
> I'm not sure I follow.  Are these changes in k.org, or in another
> repository someplace?

In k.org. 3.7 would work. 3.8-rcX would work even better.

root in a user namespace does not have permission to call TIOCCONS.

>> Is there a desire to have TIOCCONS not just fail in a container but to
>> have TIOCCONS work in a container specific way?
>
> Well, my desire is for the host console to work properly if a
> container uses TIOCCONS :-).  It seems to me that the most consistent
> way to handle this is to have TIOCCONS in a container redirect the
> container's console.

Last I looked people were creating a regulary pty and using that in
/dev/ for their containers.  So the emperical evidence is that TIOCCONS
is not needed.  What case are you looking at that needs TIOCCONS?

If there is good cause we can make TIOCCONS work but we need a
compelling case beyond root in a container can do bad things.

 The other problem is that I don't think you can call fput() from
 destroy_pid_namespace().  That can be called from interrupt context,
 and I don't think fput() is safe there.  I know it's not safe in 3.4
 with the RT patch applied.  However, the only way I've come up with to
 fix it is to add a workqueue, and that seems a bit heavy for this.
>> Actually getting destroy_pid_namespace out of interrupt context wouldn't
>> be the worst thing in the world.
>
> I would agree, but it would still require something like a workqueue.
> Is there a better mechanism?

It might be as simple as finding all of the put_pids and moving them out
of spin_lock critical sections.  I don't know that we drop pids in
actual interrupt context.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] cpufreq/intel_pstate: Add kernel command line option disable intel_pstate.

2013-02-14 Thread Viresh Kumar
On Fri, Feb 15, 2013 at 12:08 AM,   wrote:
> From: Dirk Brandewie 
>
> When intel_pstate is configured into the kernel it will become the
> perferred scaling driver for processors that is supports.  Allow the

s/perferred/preferred

s/is/it

> user to override this by adding:
>intel_pstate=disable
> on the kernel command line.
>
> Signed-off-by: Dirk Brandewie 
> ---
>  Documentation/kernel-parameters.txt |5 +
>  drivers/cpufreq/intel_pstate.c  |   16 
>  2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 6c72381..41c5d9e 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1131,6 +1131,11 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
> 0   disables intel_idle and fall back on 
> acpi_idle.
> 1 to 6  specify maximum depth of C-state.
>
> +   intel_pstate=  [X86]
> +  disable
> +Do not enable intel_pstate as the default
> +scaling driver for the supported processors
> +
> intremap=   [X86-64, Intel-IOMMU]
> on  enable Interrupt Remapping (default)
> off disable Interrupt Remapping
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index e879963..9cbb733 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -773,11 +773,16 @@ static void intel_pstate_exit(void)
>  }
>  module_exit(intel_pstate_exit);
>
> +static int no_load;
> +
>  static int __init intel_pstate_init(void)
>  {
> int rc = 0;
> const struct x86_cpu_id *id;
>
> +   if (no_load)
> +   return -ENODEV;
> +
> id = x86_match_cpu(intel_pstate_cpu_ids);
> if (!id)
> return -ENODEV;
> @@ -802,6 +807,17 @@ out:
>  }
>  device_initcall(intel_pstate_init);
>
> +static int __init intel_pstate_setup(char *str)

Parameter to this is really not required. By default intel_pstate
driver is enabled, so just past disable_intel_pstate from command line
without any args.

> +{
> +   if (!str)
> +   return -EINVAL;
> +
> +   if (!strcmp(str, "disable"))
> +   no_load = 1;
> +   return 0;
> +}
> +early_param("intel_pstate", intel_pstate_setup);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/13] kdump, vmcore: support mmap() on /proc/vmcore

2013-02-14 Thread Atsushi Kumagai
Hello HATAYAMA-san,

On Thu, 14 Feb 2013 19:11:43 +0900
HATAYAMA Daisuke  wrote:

> Currently, read to /proc/vmcore is done by read_oldmem() that uses
> ioremap/iounmap per a single page. For example, if memory is 1GB,
> ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
> times. This causes big performance degradation.
> 
> To address the issue, this patch implements mmap() on /proc/vmcore to
> improve read performance. My simple benchmark shows the improvement
> from 200 [MiB/sec] to over 50.0 [GiB/sec].

Thanks for your hard work, I think it's a good enough improvement.
 
> Benchmark
> =
> 
> = Machine spec
>   - CPU: Intel(R) Xeon(R) CPU E7- 4820 @ 2.00GHz (4 sockets, 8 cores) (*)
>   - memory: 32GB
>   - kernel: 3.8-rc6 with this patch
>   - vmcore size: 31.7GB
> 
>   (*) only 1 cpu is used in the 2nd kernel now.
> 
> = Benchmark Case
> 
> 1) copy /proc/vmcore *WITHOUT* mmap() on /proc/vmcore
> 
> $ time dd bs=4096 if=/proc/vmcore of=/dev/null
> 8307246+1 records in
> 8307246+1 records out
> real2m 31.50s
> user0m 1.06s
> sys 2m 27.60s
> 
> So performance is 214.26 [MiB/sec].
> 
> 2) copy /proc/vmcore with mmap()
> 
>   I ran the next command and recorded real time:
> 
>   $ for n in $(seq 1 15) ; do \
>   >   time copyvmcore2 --blocksize=$((4096 * (1 << (n - 1 /proc/vmcore 
> /dev/null \
>   > done
> 
>   where copyvmcore2 is an ad-hoc test tool that read data from
>   /proc/vmcore via mmap() in given block-size unit and write them to
>   some file.
> 
> |  n | map size |  time | page table | performance |
> ||  | (sec) ||   [GiB/sec] |
> |+--+---++-|
> |  1 | 4 KiB| 78.35 | 8 iB   |0.40 |
> |  2 | 8 KiB| 45.29 | 16 iB  |0.70 |
> |  3 | 16 KiB   | 23.82 | 32 iB  |1.33 |
> |  4 | 32 KiB   | 12.90 | 64 iB  |2.46 |
> |  5 | 64 KiB   |  6.13 | 128 iB |5.17 |
> |  6 | 128 KiB  |  3.26 | 256 iB |9.72 |
> |  7 | 256 KiB  |  1.86 | 512 iB |   17.04 |
> |  8 | 512 KiB  |  1.13 | 1 KiB  |   28.04 |
> |  9 | 1 MiB|  0.77 | 2 KiB  |   41.16 |
> | 10 | 2 MiB|  0.58 | 4 KiB  |   54.64 |
> | 11 | 4 MiB|  0.50 | 8 KiB  |   63.38 |
> | 12 | 8 MiB|  0.46 | 16 KiB |   68.89 |
> | 13 | 16 MiB   |  0.44 | 32 KiB |   72.02 |
> | 14 | 32 MiB   |  0.44 | 64 KiB |   72.02 |
> | 15 | 64 MiB   |  0.45 | 128 KiB|   70.42 |
> 
> 3) copy /proc/vmcore with mmap() on /dev/oldmem
> 
> I posted another patch series for mmap() on /dev/oldmem a few weeks ago.
> See: https://lkml.org/lkml/2013/2/3/431
> 
> Next is the table shown on the post showing the benchmark.
> 
> |  n | map size |  time | page table | performance |
> ||  | (sec) ||   [GiB/sec] |
> |+--+---++-|
> |  1 | 4 KiB| 41.86 | 8 iB   |0.76 |
> |  2 | 8 KiB| 25.43 | 16 iB  |1.25 |
> |  3 | 16 KiB   | 13.28 | 32 iB  |2.39 |
> |  4 | 32 KiB   |  7.20 | 64 iB  |4.40 |
> |  5 | 64 KiB   |  3.45 | 128 iB |9.19 |
> |  6 | 128 KiB  |  1.82 | 256 iB |   17.42 |
> |  7 | 256 KiB  |  1.03 | 512 iB |   30.78 |
> |  8 | 512 KiB  |  0.61 | 1K iB  |   51.97 |
> |  9 | 1 MiB|  0.41 | 2K iB  |   77.32 |
> | 10 | 2 MiB|  0.32 | 4K iB  |   99.06 |
> | 11 | 4 MiB|  0.27 | 8K iB  |  117.41 |
> | 12 | 8 MiB|  0.24 | 16 KiB |  132.08 |
> | 13 | 16 MiB   |  0.23 | 32 KiB |  137.83 |
> | 14 | 32 MiB   |  0.22 | 64 KiB |  144.09 |
> | 15 | 64 MiB   |  0.22 | 128 KiB|  144.09 |
> 
> = Discussion
> 
> - For small map size, we can see performance degradation on mmap()
>   case due to many page table modification and TLB flushes similarly
>   to read_oldmem() case. But for large map size we can see the
>   improved performance.
> 
>   Each application need to choose appropreate map size for their
>   preferable performance.
> 
> - mmap() on /dev/oldmem appears better than that on /proc/vmcore. But
>   actual processing does not only copying but also IO work. This
>   difference is not a problem.

To keep the makedumpfile code simple, I wouldn't like to use /dev/oldmem
as another input interface. And I hope that we can get enough performance 
with only /proc/vmcore.

> - Both mmap() case shows drastically better performance than previous
>   RFC patch set's about 2.5 [GiB/sec] that maps all dump target memory
>   in kernel direct mapping address space. This is because there's no
>   longer memcpy() from kernel-space to user-space.
> 
> Design
> ==
> 
> = Support Range
> 
> - mmap() on /proc/vmcore is supported on ELF64 interface only. ELF32
>   interface is used only if dump target size is less than 4GB. Then,
>   the existing interface is enough in performance.
> 
> = Change of /proc/vmcore format
> 
> For 

Re: [PATCH] virtio-spec: Define virtio-mmio registers as LE

2013-02-14 Thread Rusty Russell
Pawel Moll  writes:
> To solve the never-ending confusions between hosts and guests
> of different endianess, define all virtio-mmio registers as LE.
>
> This change should be safe at this stage, because no known
> working mixed-endian system exists so there is virtually no
> risk of breaking compatibility.
>
> Signed-off-by: Pawel Moll 

Applied.  We could also move device configuration space to LE, if we
wanted.  It's a bigger change to the Linux implementation, since we now
need accessors for each width, but it might be a good idea.  OTOH,
getting such a change into qemu might be harder...

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/4] powerpc: lookup_linux_pte has been made public

2013-02-14 Thread Paul Mackerras
On Mon, Feb 11, 2013 at 11:12:40PM +1100, a...@ozlabs.ru wrote:
> From: Alexey Kardashevskiy 
> 
> The lookup_linux_pte() function returns a linux PTE which
> is required to convert KVM guest physical address into host real
> address in real mode.
> 
> This convertion will be used by upcoming support of H_PUT_TCE_INDIRECT
> as TCE list address comes from the guest directly so it is a guest
> physical.
> 
> Signed-off-by: Alexey Kardashevskiy 
> Cc: David Gibson 
> ---
>  arch/powerpc/include/asm/pgtable-ppc64.h |3 +++
>  arch/powerpc/kvm/book3s_hv_rm_mmu.c  |4 ++--
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h 
> b/arch/powerpc/include/asm/pgtable-ppc64.h
> index 0182c20..ddcc898 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -377,6 +377,9 @@ static inline pte_t *find_linux_pte_or_hugepte(pgd_t 
> *pgdir, unsigned long ea,
>  }
>  #endif /* !CONFIG_HUGETLB_PAGE */
>  
> +pte_t lookup_linux_pte(pgd_t *pgdir, unsigned long hva,
> + int writing, unsigned long *pte_sizep);
> +

This seems a slightly odd place to put the declaration of a function
which is defined in the KVM code.  kvm-ppc.h might be a better place.

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 4/4] vfio powerpc: added real mode support

2013-02-14 Thread Paul Mackerras
On Mon, Feb 11, 2013 at 11:12:43PM +1100, a...@ozlabs.ru wrote:
> From: Alexey Kardashevskiy 
> 
> The patch allows the host kernel to handle H_PUT_TCE request
> without involving QEMU in it what should save time on switching
> from the kernel to QEMU and back.
> 
> The patch adds an IOMMU ID parameter into the KVM_CAP_SPAPR_TCE ioctl,
> QEMU needs to be fixed to support that.
> 
> At the moment H_PUT_TCE is processed in the virtual mode as the page
> to be mapped may not be present in the RAM so paging may be involved as
> it can be done from the virtual mode only.
> 
> Tests show that this patch increases tranmission speed from 220MB/s
> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
[snip]
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index b4fdabc..acb9cdc 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -47,6 +47,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #define DBG(...)
>  
> @@ -727,6 +729,7 @@ void iommu_register_group(struct iommu_table * tbl,
>   return;
>   }
>   tbl->it_group = grp;
> + INIT_LIST_HEAD(>it_hugepages);
>   iommu_group_set_iommudata(grp, tbl, group_release);
>   iommu_group_set_name(grp, kasprintf(GFP_KERNEL, "domain%d-pe%lx",
>   domain_number, pe_num));
> @@ -906,6 +909,83 @@ void kvm_iommu_unmap_pages(struct kvm *kvm, struct 
> kvm_memory_slot *slot)
>  {
>  }
>  
> +/*
> + * The KVM guest can be backed with 16MB pages (qemu switch
> + * -mem-path /var/lib/hugetlbfs/global/pagesize-16MB/).
> + * In this case, we cannot do page counting from the real mode
> + * as the compound pages are used - they are linked in a list
> + * with pointers as virtual addresses which are inaccessible
> + * in real mode.
> + *
> + * The code below keeps a 16MB pages list and uses page struct
> + * in real mode if it is already locked in RAM and inserted into
> + * the list or switches to the virtual mode where it can be
> + * handled in a usual manner.
> + */
> +struct iommu_kvmppc_hugepages {
> + struct list_head list;
> + pte_t pte;  /* Huge page PTE */
> + unsigned long pa;   /* Base phys address used as a real TCE */
> + struct page *page;  /* page struct of the very first subpage */
> + unsigned long size; /* Huge page size (always 16MB at the moment) */
> + bool dirty; /* Dirty bit */
> +};
> +
> +static struct iommu_kvmppc_hugepages *find_hp_by_pte(struct iommu_table *tbl,
> + pte_t pte)
> +{
> + struct iommu_kvmppc_hugepages *hp;
> +
> + list_for_each_entry(hp, >it_hugepages, list) {
> + if (hp->pte == pte)
> + return hp;
> + }
> +
> + return NULL;
> +}
> +
> +static struct iommu_kvmppc_hugepages *find_hp_by_pa(struct iommu_table *tbl,
> + unsigned long pa)
> +{
> + struct iommu_kvmppc_hugepages *hp;
> +
> + list_for_each_entry(hp, >it_hugepages, list) {
> + if ((hp->pa <= pa) && (pa < hp->pa + hp->size))
> + return hp;
> + }
> +
> + return NULL;
> +}
> +
> +static struct iommu_kvmppc_hugepages *add_hp(struct iommu_table *tbl,
> + pte_t pte, unsigned long va, unsigned long pg_size)
> +{
> + int ret;
> + struct iommu_kvmppc_hugepages *hp;
> +
> + hp = kzalloc(sizeof(*hp), GFP_KERNEL);
> + if (!hp)
> + return NULL;
> +
> + hp->pte = pte;
> + va = va & ~(pg_size - 1);
> + ret = get_user_pages_fast(va, 1, true/*write*/, >page);
> + if ((ret != 1) || !hp->page) {
> + kfree(hp);
> + return NULL;
> + }
> +#if defined(HASHED_PAGE_VIRTUAL) || defined(WANT_PAGE_VIRTUAL)
> +#error TODO: fix to avoid page_address() here
> +#endif
> + hp->pa = __pa((unsigned long) page_address(hp->page));
> +
> + hp->size = pg_size;
> +
> + list_add(>list, >it_hugepages);
> +
> + return hp;
> +}

I don't see any locking here.  What stops one cpu doing add_hp() from
racing with another doing find_hp_by_pte() or find_hp_by_pa()?

[snip]
> @@ -1021,6 +1123,24 @@ long iommu_clear_tce_user_mode(struct iommu_table 
> *tbl, unsigned long ioba,
>  }
>  EXPORT_SYMBOL_GPL(iommu_clear_tce_user_mode);
>  
> +long iommu_clear_tce_real_mode(struct iommu_table *tbl, unsigned long ioba,
> + unsigned long tce_value, unsigned long npages)
> +{
> + long ret;
> + unsigned long entry = ioba >> IOMMU_PAGE_SHIFT;
> +
> + ret = tce_clear_param_check(tbl, ioba, tce_value, npages);
> + if (!ret)
> + ret = clear_tce(tbl, true, entry, npages);
> +
> + if (ret < 0)
> + pr_err("iommu_tce: %s failed ioba=%lx, tce_value=%lx ret=%ld\n",
> + __func__, ioba, tce_value, ret);

Better to avoid printk in real mode if at all possible, particularly
if they're guest-triggerable.

[snip]
> @@ -195,15 +225,43 @@ long 

Re: [PATCH 2/4] powerpc kvm: added multiple TCEs requests support

2013-02-14 Thread Paul Mackerras
On Mon, Feb 11, 2013 at 11:12:41PM +1100, a...@ozlabs.ru wrote:

> +static long emulated_h_put_tce(struct kvmppc_spapr_tce_table *stt,
> + unsigned long ioba, unsigned long tce)
> +{
> + unsigned long idx = ioba >> SPAPR_TCE_SHIFT;
> + struct page *page;
> + u64 *tbl;
> +
> + /* udbg_printf("H_PUT_TCE: liobn 0x%lx => stt=%p  window_size=0x%x\n", 
> */
> + /*  liobn, stt, stt->window_size); */
> + if (ioba >= stt->window_size) {
> + pr_err("%s failed on ioba=%lx\n", __func__, ioba);

Doesn't this give the guest a way to spam the host logs?  And in fact
printk in real mode is potentially problematic.  I would just leave
out this statement.

> + return H_PARAMETER;
> + }
> +
> + page = stt->pages[idx / TCES_PER_PAGE];
> + tbl = (u64 *)page_address(page);

I would like to see an explanation of why we are confident that
page_address() will work correctly in real mode, across all the
combinations of config options that we can have for a ppc64 book3s
kernel.

> +
> + /* FIXME: Need to validate the TCE itself */
> + /* udbg_printf("tce @ %p\n", [idx % TCES_PER_PAGE]); */
> + tbl[idx % TCES_PER_PAGE] = tce;
> +
> + return H_SUCCESS;
> +}
> +
> +/*
> + * Real mode handlers
>   */
>  long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
> unsigned long ioba, unsigned long tce)
>  {
> - struct kvm *kvm = vcpu->kvm;
>   struct kvmppc_spapr_tce_table *stt;
>  
> - /* udbg_printf("H_PUT_TCE(): liobn=0x%lx ioba=0x%lx, tce=0x%lx\n", */
> - /*  liobn, ioba, tce); */
> + stt = find_tce_table(vcpu, liobn);
> + /* Didn't find the liobn, put it to userspace */
> + if (!stt)
> + return H_TOO_HARD;
> +
> + /* Emulated IO */
> + return emulated_h_put_tce(stt, ioba, tce);
> +}
> +
> +long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> + unsigned long liobn, unsigned long ioba,
> + unsigned long tce_list, unsigned long npages)
> +{
> + struct kvmppc_spapr_tce_table *stt;
> + long i, ret = 0;
> + unsigned long *tces;
> +
> + stt = find_tce_table(vcpu, liobn);
> + /* Didn't find the liobn, put it to userspace */
> + if (!stt)
> + return H_TOO_HARD;
>  
> - list_for_each_entry(stt, >arch.spapr_tce_tables, list) {
> - if (stt->liobn == liobn) {
> - unsigned long idx = ioba >> SPAPR_TCE_SHIFT;
> - struct page *page;
> - u64 *tbl;
> + tces = (void *) get_real_address(vcpu, tce_list, false, NULL, NULL);
> + if (!tces)
> + return H_TOO_HARD;
>  
> - /* udbg_printf("H_PUT_TCE: liobn 0x%lx => stt=%p  
> window_size=0x%x\n", */
> - /*  liobn, stt, stt->window_size); */
> - if (ioba >= stt->window_size)
> - return H_PARAMETER;
> + /* Emulated IO */
> + for (i = 0; (i < npages) && !ret; ++i, ioba += IOMMU_PAGE_SIZE)
> + ret = emulated_h_put_tce(stt, ioba, tces[i]);

So, tces is a pointer to somewhere inside a real page.  Did we check
somewhere that tces[npages-1] is in the same page as tces[0]?  If so,
I missed it.  If we didn't, then we probably should check and do
something about it.

>  
> - page = stt->pages[idx / TCES_PER_PAGE];
> - tbl = (u64 *)page_address(page);
> + return ret;
> +}
>  
> - /* FIXME: Need to validate the TCE itself */
> - /* udbg_printf("tce @ %p\n", [idx % 
> TCES_PER_PAGE]); */
> - tbl[idx % TCES_PER_PAGE] = tce;
> - return H_SUCCESS;
> - }
> - }
> +long kvmppc_h_stuff_tce(struct kvm_vcpu *vcpu,
> + unsigned long liobn, unsigned long ioba,
> + unsigned long tce_value, unsigned long npages)
> +{
> + struct kvmppc_spapr_tce_table *stt;
> + long i, ret = 0;
> +
> + stt = find_tce_table(vcpu, liobn);
> + /* Didn't find the liobn, put it to userspace */
> + if (!stt)
> + return H_TOO_HARD;
>  
> - /* Didn't find the liobn, punt it to userspace */
> - return H_TOO_HARD;
> + /* Emulated IO */
> + for (i = 0; (i < npages) && !ret; ++i, ioba += IOMMU_PAGE_SIZE)
> + ret = emulated_h_put_tce(stt, ioba, tce_value);
> +
> + return ret;
> +}
> +
> +/*
> + * Virtual mode handlers
> + */
> +extern long kvmppc_virtmode_h_put_tce(struct kvm_vcpu *vcpu,
> + unsigned long liobn, unsigned long ioba,
> + unsigned long tce)
> +{
> + /* At the moment emulated IO is handled the same way */
> + return kvmppc_h_put_tce(vcpu, liobn, ioba, tce);
> +}
> +
> +extern long kvmppc_virtmode_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> + unsigned long liobn, unsigned long ioba,
> + unsigned long tce_list, unsigned long 

Re: [PATCH 3/4] powerpc: preparing to support real mode optimization

2013-02-14 Thread Paul Mackerras
On Mon, Feb 11, 2013 at 11:12:42PM +1100, a...@ozlabs.ru wrote:
> From: Alexey Kardashevskiy 
> 
> he current VFIO-on-POWER implementation supports only user mode
> driven mapping, i.e. QEMU is sending requests to map/unmap pages.
> However this approach is really slow in really fast hardware so
> it is better to be moved to the real mode.
> 
> The patch adds an API to increment/decrement page counter as
> get_user_pages API used for user mode mapping does not work
> in the real mode.
> 
> CONFIG_SPARSEMEM_VMEMMAP and CONFIG_FLATMEN are supported.
> 
> Signed-off-by: Alexey Kardashevskiy 
> Cc: David Gibson 
> ---

The names are slightly odd, in that they include "vmemmap_" but exist
and work in the flatmem case as well.  Apart from that...

Reviewed-by: Paul Mackerras 

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] pci: Disable slot presence detection around bus reset

2013-02-14 Thread Alex Williamson
On Thu, 2013-02-14 at 16:47 -0700, Bjorn Helgaas wrote:
> On Thu, Feb 14, 2013 at 11:37 AM, Alex Williamson
>  wrote:
> > A bus reset can trigger a presence detection change and result in a
> > suprise hotplug.  This is generally not what we want to happen when
> > trying to reset a device.  Disable the presence detection control on
> > on bridges around bus reset.
> 
> This is a really interesting situation, and I'm not quite ready to
> sign up to the idea that this is really a problem and that if it is,
> this is the way we want to fix it.
> 
> What would happen if we *did* handle this as a hotplug event, with a
> removal followed by an add?
> 
> The scheme where pci_reset_function() does "pci_save_state(dev);
> pci_dev_reset(dev); pci_restore_state(dev);" makes me nervous.
> 
> We're saving and restoring some of PCI config space around the reset,
> but there's no guarantee that we're preserving *all* the important
> state in config space because I think devices can have non-architected
> device-specific things in config space that we don't know how to
> save/restore.
> 
> Devices also have internal state not exposed via config space.  That
> state is lost during the reset but can't be restored by
> pci_restore_state().  So it seems like pci_reset_function() is
> pretending to do something it can't really do reliably.
> 
> If we make it so a reset is always handled as a remove+add, then we'll
> use a more generic path, and we'll get all the stuff you expect when
> initializing a new device -- resource assignment, IRQ setup, quirks,
> etc.  Quirks in particular seem like something we want, but don't
> currently get with pci_reset_function().
> 
> Oh, and the "disable presence detect" approach below only works for
> things below a PCIe bridge with native hotplug, right?  I wonder what
> happens if we reset devices below a bridge using SHPC or acpiphp.

Triggering a remove+add is not useful for the way we use it today.  The
users I'm aware of are KVM device assignment and VFIO, where we trigger
it in an attempt to get the device to a known state so that we have some
hope of repeatability.  In those scenarios the reset is initiated by the
driver.  The interface isn't meant to guarantee the device is returned
to an identical state as it was before reset.  If it did, why would we
call it?  We want to get to a state as near to power on, but still with
config programming, as we can.

Being driver directed, having the reset initiate a remove is pretty near
the last thing we want.  That limits the scope of calling it to only
when the driver can readily release the device.  If we have the device
attached to a guest or userspace driver, that's potentially a lot of
setup and teardown and effectively extending a surprise removal all the
way up the stack.

Obviously a bus reset is a big hammer and we do exhaust all the little
hammers of flr and pm reset before we try it, but in this case, we know
the device that's going away and with all likelihood, it's coming right
back at the same location.  If we take the path of forcing a remove+add,
let's just remove it from the reset_function call path and we'll do
without reset for those devices.  Thanks,

Alex

> > Signed-off-by: Alex Williamson 
> > ---
> >  drivers/pci/pci.c |   29 -
> >  1 file changed, 24 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 5cb5820..c1f7d77 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -3229,8 +3229,8 @@ static int pci_pm_reset(struct pci_dev *dev, int 
> > probe)
> >
> >  static int pci_parent_bus_reset(struct pci_dev *dev, int probe)
> >  {
> > -   u16 ctrl;
> > -   struct pci_dev *pdev;
> > +   u16 ctrl, flags, sltctl = 0;
> > +   struct pci_dev *pdev, *bridge;
> >
> > if (pci_is_root_bus(dev->bus) || dev->subordinate || 
> > !dev->bus->self)
> > return -ENOTTY;
> > @@ -3242,15 +3242,34 @@ static int pci_parent_bus_reset(struct pci_dev 
> > *dev, int probe)
> > if (probe)
> > return 0;
> >
> > -   pci_read_config_word(dev->bus->self, PCI_BRIDGE_CONTROL, );
> > +   bridge = dev->bus->self;
> > +
> > +   /*
> > +* If the parent device supports a slot with presence detection
> > +* change enabled, holding the bus in reset can trigger that and
> > +* cause an unwanted surprise removal.  Disable presence detection
> > +* around the bus reset.
> > +*/
> > +   pcie_capability_read_word(bridge, PCI_EXP_FLAGS, );
> > +   if (flags & PCI_EXP_FLAGS_SLOT) {
> > +   pcie_capability_read_word(bridge, PCI_EXP_SLTCTL, );
> > +   if (sltctl & PCI_EXP_SLTCTL_PDCE)
> > +   pcie_capability_write_word(bridge, PCI_EXP_SLTCTL,
> > +   sltctl & 
> > ~PCI_EXP_SLTCTL_PDCE);
> > +   }
> > +
> > +   pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, );

Re: Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())

2013-02-14 Thread Andrew Bartlett
On Thu, 2013-02-14 at 18:52 +0900, Namjae Jeon wrote:
> [snip]
> >> >
> >> > Thanks,
> >> Hi Andrew.
> >>
> >> First, Thanks for your interest !
> >> A mismatch between inode size and reserved blocks can be either due to
> >> pre-allocation (after our changes) or due to corruption (sudden unplug
> >> of media etc).
> >> We don’t think it is right to include only read only support (i.e.
> >> without fallocate support) for such files because if such files are
> >> encountered it only means that the file is corrupted, as there is no
> >> current method to check if the issue is due to pre-allocation.
> >> If it is to be included in the kernel, then the whole patch has to go
> >> in.
> >
> > I don't see why that is the case.
> If we consider that there is no FALLOCATE support, then the condition
> of file size and blocks not matching can be only possible in case of
> corruption, right?

Sure.  I was just suggesting we transparently recover from that, by
using the blocks.  Think of it more as an online fsck not about
fallocate. 

Anyway, if you don't think it's reasonable to use those blocks, or to
'just fix it', then we just have to continue to do as we currently do.
That is on first sign of FS corruption just stop doing writes, and await
an FSCK.  

> >> But then again, since the FAT specifications do not accommodate
> >> for pre-allocation, then it is up to OGAWA to decide if this is
> >> acceptable.
> >> In any case, the patch will definitely break backward compatibility
> >> (on an older fat driver without fallocate support) and also in case
> >> for the two variants for the same kernel versions and only one has
> >> FALLOCATE enabled, in such cases also, the behavior will assume
> >> corruption in one case.
> >
> > I agree that the sudden unplug is a concern, but why not make the
> > filesystem more robust against that inevitable occurrence?  If the
> > blocks appear to be allocated to the file, why not use them?
> We also agree that there should be pre-allocation feature on FAT, and
> we had shared the scenarios where this could be required for a TV/
> recorder.
> But there are certain drawbacks which were raised by OGAWA with
> respect to compatibility and we also tend to agree on them.
> There could possibly be an issue where we are unable to distinguish
> between pre-allocation and corruption. Perhaps we could set a status
> bit on the file to indicate whether the file has pre-allocated blocks.
> This will make it clear whether the allocation is genuine through the
> FAT Fallocate request or is a result of corruption. Depending on the
> status of the flag - the decision can be made regard to reading
> blocks.
> But, the main issue in this will be storing this bit in on-disk
> directory entry for that file. From the feature and usability point of
> view, we should have fallocate on FAT too.
> 
> But it needs initial ACK from OGAWA to continue to work on this so
> that we can figure out the proper solution to move forward.

OK.  Given the need to find other approaches, I wanted to suggest some
ideas - some of which you may have already considered:

What about having a shadow FAT in a file, say called 'allocated space',
that would contain inode -> cluster list pairs, and where that file
would itself contain the free space the 'belongs' to other files?

As new clusters become needed in a file, they would simply be removed
from the 'allocated space' file, and assigned to the file they really
belong to.  That way, another OS just sees a large file, nothing more. 

Or, if we cannot make any changes to the on-disk format, what about
keeping such a database in memory, allocating some of the existing free
list to files that have had fallocate() called on them?  (Naturally,
this makes it non-persistent, and instead more of a 'hint', but could at
least solve our mutual performance issues). 

Or, could we leave allocated but unused clusters in the free cluster
list, but maintain a file with a hint that a particular file should use
a particular free cluster next, if available?  That list of 'allocated
free' clusters could be honoured by fallocate-aware OSs to reduce df and
increase du, but be ignored by other OSs, ensuring you could not run out
of space expanding a file in another OS.  

If a cluster was observed no longer to be in the real free list, it
would be ignored in the 'allocated free' list, to avoid corruption. 

In short, I see the restriction on not breaking existing implementations
as a difficult, but certainty not impossible problem. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] powerpc: fixing ptrace_get_reg to return an error

2013-02-14 Thread Alexey Kardashevskiy
Currently ptrace_get_reg returns error as a value
what make impossible to tell whether it is a correct value or error code.

The patch adds a parameter which points to the real return data and
returns an error code.

As get_user_msr() never fails and it is used in multiple places so it has not
been changed by this patch.

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/ptrace.h |3 ++-
 arch/powerpc/kernel/ptrace.c  |   29 ++---
 arch/powerpc/kernel/ptrace32.c|   15 ---
 3 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/include/asm/ptrace.h 
b/arch/powerpc/include/asm/ptrace.h
index 5f99568..becc08e 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -92,7 +92,8 @@ static inline long regs_return_value(struct pt_regs *regs)
} while(0)
 
 struct task_struct;
-extern unsigned long ptrace_get_reg(struct task_struct *task, int regno);
+extern int ptrace_get_reg(struct task_struct *task, int regno,
+ unsigned long *data);
 extern int ptrace_put_reg(struct task_struct *task, int regno,
  unsigned long data);
 
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 245c1b6..d5ff7ea 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -180,9 +180,10 @@ static int set_user_msr(struct task_struct *task, unsigned 
long msr)
 }
 
 #ifdef CONFIG_PPC64
-static unsigned long get_user_dscr(struct task_struct *task)
+static int get_user_dscr(struct task_struct *task, unsigned long *data)
 {
-   return task->thread.dscr;
+   *data = task->thread.dscr;
+   return 0;
 }
 
 static int set_user_dscr(struct task_struct *task, unsigned long dscr)
@@ -192,7 +193,7 @@ static int set_user_dscr(struct task_struct *task, unsigned 
long dscr)
return 0;
 }
 #else
-static unsigned long get_user_dscr(struct task_struct *task)
+static int get_user_dscr(struct task_struct *task, unsigned long *data)
 {
return -EIO;
 }
@@ -216,19 +217,23 @@ static int set_user_trap(struct task_struct *task, 
unsigned long trap)
 /*
  * Get contents of register REGNO in task TASK.
  */
-unsigned long ptrace_get_reg(struct task_struct *task, int regno)
+int ptrace_get_reg(struct task_struct *task, int regno, unsigned long *data)
 {
-   if (task->thread.regs == NULL)
+   if ((task->thread.regs == NULL) || !data)
return -EIO;
 
-   if (regno == PT_MSR)
-   return get_user_msr(task);
+   if (regno == PT_MSR) {
+   *data = get_user_msr(task);
+   return 0;
+   }
 
if (regno == PT_DSCR)
-   return get_user_dscr(task);
+   return get_user_dscr(task, data);
 
-   if (regno < (sizeof(struct pt_regs) / sizeof(unsigned long)))
-   return ((unsigned long *)task->thread.regs)[regno];
+   if (regno < (sizeof(struct pt_regs) / sizeof(unsigned long))) {
+   *data = ((unsigned long *)task->thread.regs)[regno];
+   return 0;
+   }
 
return -EIO;
 }
@@ -1559,7 +1564,9 @@ long arch_ptrace(struct task_struct *child, long request,
 
CHECK_FULL_REGS(child->thread.regs);
if (index < PT_FPR0) {
-   tmp = ptrace_get_reg(child, (int) index);
+   ret = ptrace_get_reg(child, (int) index, );
+   if (ret)
+   break;
} else {
unsigned int fpidx = index - PT_FPR0;
 
diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
index c0244e7..f51599e 100644
--- a/arch/powerpc/kernel/ptrace32.c
+++ b/arch/powerpc/kernel/ptrace32.c
@@ -95,7 +95,9 @@ long compat_arch_ptrace(struct task_struct *child, 
compat_long_t request,
 
CHECK_FULL_REGS(child->thread.regs);
if (index < PT_FPR0) {
-   tmp = ptrace_get_reg(child, index);
+   ret = ptrace_get_reg(child, index, );
+   if (ret)
+   break;
} else {
flush_fp_to_thread(child);
/*
@@ -148,7 +150,11 @@ long compat_arch_ptrace(struct task_struct *child, 
compat_long_t request,
tmp = ((u64 *)child->thread.fpr)
[FPRINDEX_3264(numReg)];
} else { /* register within PT_REGS struct */
-   tmp = ptrace_get_reg(child, numReg);
+   unsigned long tmp2;
+   ret = ptrace_get_reg(child, numReg, );
+   if (ret)
+   break;
+   tmp = tmp2;
} 
reg32bits = ((u32*))[part];
ret = put_user(reg32bits, (u32 __user *)data);
@@ -232,7 +238,10 @@ long 

  1   2   3   4   5   6   7   8   9   10   >