regulators: creating a regulator device for the AC/USB/BAT/charge component of a PMIC?

[Stephen Warren]

Mark, Liam,

A couple of the regulators I'm looking at (I guess many/most in fact)
are structured as:

Battery, AC, USB, ... -> PMIC -> main output (unregulated?)

main output -> PMIC input pins for some of the SW-controllable
regulators. This is an external connection on the board.

Should this "main output" be represented as a regulator itself?

In more graphical/concrete terms, take the TPS6586x:

+---+
|   |
AC  --> | \ |
USB --> |  |--> SYS | >---\
BAT --> | / | |
|   VIN_SM0 | <---/
| v |
|   SM0 OUT | ---> other devices
...

... where SM0 is one of the regulators the driver already exposes.

I assume SYS should be an explicit regulator device, because all the
other regulators within the PMIC can be set up to require that a supply
be specified (in the DT, a vin-sm0-supply property is mandatory for the
TPS6586x driver), so some regulator object must exist and be provided as
the supply.

The alternative would be to this would be to ignore this aspect of the
PMIC, and just create a standalone fixed regulator to act as the supply
for the SM0 regulator. However, this doesn't seem like an accurate model
of the HW.

However, some of the regulators in the TPS6586x at least are fed
directly from the SYS output by an internal connection within the PMIC
(e.g. LDO5). Currently, the driver sets up these regulators as having no
supply, which seems wrong too. Presumably the PMIC driver should
internally hook up its SYS as LDO5's supply without needing any platform
data or DT ldo5-supply property to do this?

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

Re: [RFC PATCH 12/13] driver core: firmware loader: use small timeout for cache device firmware

[Borislav Petkov]

On Thu, Jul 26, 2012 at 11:48:17PM +0800, Ming Lei wrote:
> On Thu, Jul 26, 2012 at 8:36 PM, Borislav Petkov  wrote:
> > On Wed, Jul 25, 2012 at 01:00:12AM +0800, Ming Lei wrote:
> >> Because device_cache_firmwares only cache the firmware which has been
> >> loaded sucessfully at leat once, using a small loading timeout should
> >
> > least
> >
> >> be OK.
> >
> > Your commit message doesn't explain why exactly we decrease the timeout:
> 
> I have explained it. Because the firmware has been loaded successfully at 
> least
> once, so it is very probably to not timeout.
> 
> > you should probably say that this patch overrides the default 60s
> > timeout because we're in pre-suspend/-hibernate mode where we have
> > userspace and are able to load the firmware quickly.
> 
> No, it is not what I was saying.

Ok, maybe I'm not understanding this then. So explain to me this: why
do you need that timeout value of 10, how did we decide it to be 10
(and not 20 or 30 or whatever)? Generally, why do we need to reprogram
the timer to a smaller timeout instead of simply doing the completion
without a timeout?

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] Problem with commit cf03c5dac83609f09d9f0e9fa3c09d86daed614d

[Dirk Gouders]

Seth Forshee  writes:

> On Thu, Jul 26, 2012 at 05:07:57PM +0200, Dirk Gouders wrote:
>> Hi Seth,
>> 
>> thanks for your reply and sorry for the noise.
>> 
>> I followed your advice and tried to boot with the WLAN interface turned
>> off, and the problem still exists.  I'll start a new bisect session,
>> probably with one of the commits you mentioned as the first good commit.
>
> Just to make sure three's not any confusion ...
>
> What I was suggesting was not just disabling the network interface but
> completely preventing brcmsmac from being loaded. The oops you saw
> happens in the context of the driver's probe function and would happen
> regardless of whether or not the interface is enabled.

Sorry for the confusion.

I already started a new bisect session, with a bad commit I disabled
brcmsmac in the kernel config and the problem still exists.  Now, I
continue with brcmsmac disabled and will see where the bisect ends.

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

[GIT PATCH] char/misc patches for 3.6-rc1

[Greg KH]

The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:

  Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-3.6-rc1

for you to fetch changes up to 6078188e2ba1d61a2119ddb2289e88c2c2a015ab:

  mei: use module_pci_driver (2012-07-19 15:33:30 -0700)


CHAR/MISC patches for 3.6-rc1

Here's the "big" pull request for 3.6-rc1 for the char/misc drivers.

It's really just a few updates to the mei driver, plus 4 other tiny patches,
nothing big at all.

Signed-off-by: Greg Kroah-Hartman 


Alexandre Pereira da Silva (1):
  misc: at25: Parse dt settings

Camuso, Tony (1):
  misc: hpilo: increase number of max supported channels

Devendra Naga (1):
  powerpc/BSR: cleanup the error path of bsr_init

Greg Kroah-Hartman (1):
  Merge 3.5-rc7 into char-misc-next.

Tomas Winkler (14):
  mei: mei.txt: minor grammar fixes
  mei: check for error codes that mei_flow_ctrl_creds retuns
  mei: make mei_write_message more readable
  mei: mei_irq_thread_write_handler check for overflow
  mei: group wd_interface_reg with watchdog variables within struct 
mei_device
  mei: don't query HCSR for host buffer depth
  mei: revamp host buffer interface function
  mei: mei_device can be const for mei register access functions
  mei: remove write only wariable wd_due_counter
  mei: mei_wd_host_init: update the comment
  mei: introduce mei_data2slots wrapper
  mei: streamline the _mei_irq_thread_close/ioctol functions
  mei: mei_irq_thread_write_handler - line break fix
  mei: use module_pci_driver

 Documentation/devicetree/bindings/misc/at25.txt |   21 +++
 Documentation/misc-devices/mei/mei.txt  |   14 +-
 drivers/char/bsr.c  |6 +-
 drivers/misc/eeprom/at25.c  |   61 +---
 drivers/misc/hpilo.c|   33 +++--
 drivers/misc/hpilo.h|4 +-
 drivers/misc/mei/init.c |4 +-
 drivers/misc/mei/interface.c|   85 +---
 drivers/misc/mei/interface.h|   18 ++-
 drivers/misc/mei/interrupt.c|  169 ++-
 drivers/misc/mei/iorw.c |8 +-
 drivers/misc/mei/main.c |   48 +--
 drivers/misc/mei/mei_dev.h  |   24 ++--
 drivers/misc/mei/wd.c   |6 +-
 14 files changed, 242 insertions(+), 259 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/at25.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PATCH] Driver core merge for 3.6-rc1

[Greg KH]

The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:

  Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ 
tags/driver-core-3.6-rc1

for you to fetch changes up to 6791457a090d9a234a40b501c2536f0aefaeae4b:

  printk: Export struct log size and member offsets through vmcoreinfo 
(2012-07-19 17:14:18 -0700)


Driver core merge for 3.6-rc1

Here's the big driver core pull request for 3.6-rc1.

Unlike 3.5, this kernel should be a lot tamer, with the printk changes now
settled down.  All we have here is some extcon driver updates, w1 driver
updates, a few printk cleanups that weren't needed for 3.5, but are good to
have now, and some other minor fixes/changes in the driver core.

All of these have been in the linux-next releases for a while now.

Signed-off-by: Greg Kroah-Hartman 


Andrew Morton (1):
  sysfs: fail dentry revalidation after namespace change fix

Arend van Spriel (1):
  debugfs: change parameter check in debugfs_remove() functions

Axel Lin (2):
  extcon: Set platform drvdata in gpio_extcon_probe() and fix irq leak
  extcon: Convert extcon_gpio to devm_gpio_request_one

Chanwoo Choi (1):
  extcon: MAX77693: Add extcon-max77693 driver to support Maxim MAX77693 
MUIC device

Devendra Naga (1):
  w1: cleanup w1_uevent

Glauber Costa (1):
  sysfs: fail dentry revalidation after namespace change

Greg Kroah-Hartman (3):
  Revert "w1: introduce a slave mutex for serializing IO"
  Merge v3.5-rc5 into driver-core-next
  Merge 3.5-rc7 into driver-core-next

Hans de Goede (1):
  device-core: Ensure drvdata = NULL when no driver is bound

K. Y. Srinivasan (1):
  Drivers: hv: Change the hex constant to a decimal constant

Kay Sievers (4):
  kmsg - properly print over-long continuation lines
  kmsg - avoid warning for CONFIG_PRINTK=n compilations
  kmsg - export "continuation record" flag to /dev/kmsg
  kmsg - do not flush partial lines when the console is busy

Lars-Peter Clausen (2):
  driver-core: Move kobj_to_dev from genhd.h to device.h
  driver-core: Use kobj_to_dev instead of re-implementing it

Mark Brown (5):
  Extcon: Staticise extcon_class
  Extcon: Arizona: Add driver for Wolfson Arizona class devices
  driver core: Move deferred devices to the end of dpm_list before probing
  extcon: arizona: Update cable reporting calls and split headset
  extcon: arizona: Stop microphone detection if we give up on it

Markus Franke (1):
  w1: Add 1-wire slave device driver for DS28E04-100

Mel Gorman (1):
  stable: Allow merging of backports for serious user-visible performance 
issues

Ming Lei (1):
  driver core: fix shutdown races with probe/remove(v3)

MyungJoo Ham (1):
  MAINTAINERS: Add entries for extcon (external connector) subsystem.

NeilBrown (4):
  w1: introduce a slave mutex for serializing IO
  w1: omap_hdq: Fix some error/debug handling.
  w1: omap_hdq: use wait_event_timeout to wait for read to complete.
  W1: split master mutex to avoid deadlocks.

Otavio Salvador (1):
  w1: Fix a typo in 'hardware' word

Paul Gortmaker (1):
  stable: update references to older 2.6 versions for 3.x

Peter Meerwald (1):
  extcon: spelling of detach in function doc

Rabin Vincent (1):
  driver core: always handle dpm_order

Rafael J. Wysocki (1):
  PM / Runtime: Do not increment device usage counts before probing

Randy Dunlap (1):
  driver core: fix some kernel-doc warnings in dma*.c

Sebastian Ott (2):
  driver core: move uevent call to driver_register
  driver core: don't trigger uevent after failure

Vivek Goyal (1):
  printk: Export struct log size and member offsets through vmcoreinfo

 Documentation/ABI/stable/sysfs-driver-w1_ds28e04 |   15 +
 Documentation/ABI/testing/dev-kmsg   |   29 +-
 Documentation/stable_kernel_rules.txt|   19 +-
 Documentation/w1/slaves/w1_ds28e04   |   36 +
 MAINTAINERS  |8 +
 drivers/base/bus.c   |1 -
 drivers/base/core.c  |   71 +-
 drivers/base/dd.c|   20 +-
 drivers/base/dma-buf.c   |1 +
 drivers/base/dma-coherent.c  |1 +
 drivers/base/driver.c|6 +-
 drivers/base/firmware_class.c|6 +-
 drivers/extcon/Kconfig   |   18 +
 drivers/extcon/Makefile  |2 +
 drivers/extcon/extcon-arizona.c  |  490 ++
 drivers/extcon/extcon-max77693.c |  779 ++
 drivers/extcon/extcon_class.c

Re: [RFC PATCH 08/13] driver core: firmware loader: fix device lifetime

[Borislav Petkov]

On Thu, Jul 26, 2012 at 11:44:48PM +0800, Ming Lei wrote:
> On Thu, Jul 26, 2012 at 8:20 PM, Borislav Petkov  wrote:
> >
> > Ok, here's what I got from looking at the patch:
> >
> > Your commit message says: "Also request_firmware_nowait should be called
> > in atomic context now, so fix the obsolete comments."
> >
> > Atomic context in my book means you're not allowed to sleep at all.
> 
> In fact, I mean the function can be called in atomic context now, and
> I know some time ago the function will create kthread to execute
> the request_firmware, and atomic context is not allowed.

Right, but when called with GFP_KERNEL mask, it can sleep, right?

> > But the comment says that it is possible to sleep a little. This is very
> > wrongly formulated AFAICT.
> 
> The function can be run in both contexts, and I don't see any words which
> says the function will sleep.

"
...
 *  Asynchronous variant of request_firmware() for user contexts where
 *  it is not possible to sleep for long time.
 **/
"

Not possible to sleep for a long time means the function still *can*
sleep... even for short time. For a certain definion of "short."

> > But, since request_firmware_nowait receives a GFP mask as one of its
> > arguments and some of its callers don't supply GFP_ATOMIC then this
> > has nothing to do with atomic contexts at all. Then, you should simply
> > explain in the comment why exactly callers aren't allowed to be sleeping
> > for a long time. And using adjectives like "long" or "short" is very
> > misleading in such explanations so please be more specific as to why the
> 
> It is the original one, and I don't think it is wrong. Also it
> shouldn't be covered
> by this patch.
> 
> Maybe I shouldn't have fixed the comment in this patch.

Why, simply fix the comment to adhere to what the function does. And
since it can sleep, maybe the easiest fix is to say simply that:
"function can sleep", right?

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:x86:fpu 2/2] arch/x86/kernel/signal.c:626:4: error: implicit declaration of function '__setup_frame'

[Suresh Siddha]

On Thu, 2012-07-26 at 07:27 +0800, Fengguang Wu wrote:
> Hi Suresh,
> 
> Kernel build failed on
> 
> tree:   tip/x86/fpu x86/fpu
> head:   29221d4b89d4e50f05ade42ad3b22e92bb564ca4
> commit: 29221d4b89d4e50f05ade42ad3b22e92bb564ca4 [2/2] x86, fpu: Unify signal 
> handling code paths for x86 and x86_64 kernels
> config: x86_64-randconfig-s003 (attached as .config)
> 
> All related error/warning messages:
> 
> arch/x86/kernel/signal.c: In function 'setup_rt_frame':
> arch/x86/kernel/signal.c:626:4: error: implicit declaration of function 
> '__setup_frame' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> --
> arch/x86/kernel/xsave.c: In function 'save_fsave_header':
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: 'X86_FXSR_MAGIC' undeclared (first use 
> in this function)
> arch/x86/kernel/xsave.c:145:7: note: each undeclared identifier is reported 
> only once for each function it appears in
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c:145:7: error: dereferencing pointer to incomplete type
> arch/x86/kernel/xsave.c: In function 'save_user_xstate':
> arch/x86/kernel/xsave.c:209:15: warning: ignoring return value of 
> '__clear_user', declared with attribute warn_unused_result [-Wunused-result]
> 

Appended the patch for this. Thanks!
---
From: Suresh Siddha 
Subject: x86, fpu: fix x86_64 build without CONFIG_IA32_EMULATION

Fengguang's automated build reported some compilation failures:
> arch/x86/kernel/signal.c: In function 'setup_rt_frame':
> arch/x86/kernel/signal.c:626:4: error: implicit declaration of function 
> '__setup_frame'
> arch/x86/kernel/xsave.c: In function 'save_fsave_header':
> arch/x86/kernel/xsave.c:144:7: error: dereferencing pointer to incomplete type
> ...

Fix x86_64 kernel build without CONFIG_IA32_EMULATION.

Code saving fsave prefix is applicable only for CONFIG_X86_32 or
CONFIG_IA32_EMULATION. Use config_enabled() checks to remove the unnecessary
code compile-time for x86_64 kernels build without CONFIG_IA32_EMULATION.

Also while we are at this, fix a spurious warning:
> arch/x86/kernel/xsave.c:209:15: warning: ignoring return value of 
> ‘__clear_user’, declared with attribute warn_unused_result

Signed-off-by: Suresh Siddha 
---
 arch/x86/include/asm/fpu-internal.h |2 +-
 arch/x86/kernel/xsave.c |   10 --
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 35ad161..5779184 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -22,7 +22,7 @@
 #include 
 #include 
 
-#ifdef CONFIG_IA32_EMULATION
+#ifdef CONFIG_X86_64
 # include 
 # include 
 int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index 2917e34..a23d100 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -205,8 +205,8 @@ static inline int save_user_xstate(struct xsave_struct 
__user *buf)
else
err = fsave_user((struct i387_fsave_struct __user *) buf);
 
-   if (unlikely(err))
-   __clear_user(buf, xstate_size);
+   if (unlikely(err) && __clear_user(buf, xstate_size))
+   err = -EFAULT;
return err;
 }
 
@@ -236,6 +236,9 @@ int save_xstate_sig(void __user *buf, void __user *buf_fx, 
int size)
struct task_struct *tsk = current;
int ia32_fxstate = (buf != buf_fx);
 
+  

Re: [PATCH 02/17] perf: Add ability to attach user level registers dump to sample

[Stephane Eranian]

On Wed, Jul 25, 2012 at 8:27 PM, Jiri Olsa  wrote:
> On Wed, Jul 25, 2012 at 07:39:18PM +0200, Stephane Eranian wrote:
>> On Sun, Jul 22, 2012 at 2:14 PM, Jiri Olsa  wrote:
>
> SNIP
>
>> > +   if (sample_type & PERF_SAMPLE_REGS_USER) {
>> > +   u64 avail = (data->regs_user != NULL);
>> > +
>> > +   /*
>> > +* If there are no regs to dump, notice it through
>> > +* first u64 being zero.
>> > +*/
>> > +   perf_output_put(handle, avail);
>> > +
>> The only role of avail is to report whether or not you've captured actual
>> registers. Could it be used to report the sampled process ABI (32 vs. 64)
>> instead? Something like:
>>   PERF_SAMPLE_REGS_ABI_NONE -> no regs captured (emulate your
>> current behavior)
>>   PERF_SAMPLE_REGS_ABI_32 -> 32 bit ABI regs captured
>>   PERF_SAMPLE_REGS_ABI_64 -> 64 bit ABI regs captured
>>
>> That could help the tools interpret the register values.
>
> Yes, I think that could help once we start dealing with compat tasks.
>
You don't control whether or not you capture compat tasks. So
you have to deal with those right now.

> The current userspace code stays untouched, because it checks for
> 'avail != 0', which stays even with your change.
>
> I think this could be sent later with all other fixes I'm already
> working on. But I can work/send it preferentially before whole patchset
> is taken if you like.
>
Well, why not do it now. You'd have to rename the available field
into something more sensible. Also need to prepare it for future
extension if they ever become necessary.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7] kdb: Mark safe commands as KDB_SAFE and KDB_SAFE_NO_ARGS

[Anton Vorontsov]

On Thu, Jul 26, 2012 at 06:07:09PM +0100, Alan Cox wrote:
> > The following commands were marked as "safe":
> > 
> > Clear Breakpoint
> > Enable Breakpoint
> > Disable Breakpoint
> > Display exception frame
> > Stack traceback
> 
> This is sufficient to steal cryptographic keys in many environments. In
> fact you merely need two or three breakpoints and to log the order they
> are hit through the crypto computation.

Neat. :-)

Breakpoints are no good then.

> > Display stack for process
> 
> Exposes all sorts of user data unless you mean just the call trace, in
> which case it's still quite useful.
> 
> > Display stack all processes
> 
> Ditto

What I think is, should we just mark single stepping (as well as
breakpoints) as unsafe, then it's hard to impossible to use the call
trace as something meaningful?

> > Send a signal to a process
> 
> Like say sending SIGSTOP to security monitoring threads or the battery
> manager on locked devices that rely on software battery management ?

Yeah, will need to zap it too.

> It's an interesting idea but you need almost nothing to extract keys from
> a system or to subvert it.

Apart from the above issues?


(Now it might seem that we cut almost everything from the KDB, but KDB is
not just about ordinary debugging facilities, like breakpoints or
variables watch. KDB is a shell that also implements commands to query
kernel about its state: e.g. in Android case there is "irqs" commands that
just shows interrupts counters, that is a nice feature if used w/ KDB
NMI/FIQ debugger[1], so you can see which interrupt is misbehaving.
There is also a 'dmesg' command, and 'summary' and maybe others.)

Thanks!

[1] http://lwn.net/Articles/506673/

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

Re: [PATCH] uprobes: don't enable/disable signle step if the user did it

[Sebastian Andrzej Siewior]

On 07/26/2012 05:20 PM, Sebastian Andrzej Siewior wrote:

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f935327..772eb3a 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1528,7 +1528,10 @@ static void handle_swbp(struct pt_regs *regs)

utask->state = UTASK_SSTEP;
if (!pre_ssout(uprobe, regs, bp_vaddr)) {
-   user_enable_single_step(current);
+   if (test_tsk_thread_flag(current, TIF_SINGLESTEP))
+   uprobe->flags |= UPROBE_USER_SSTEP;
+   else
+   user_enable_single_step(current);


After looking at it for a bit I noticed that the state should be saved
in utask intead of uprobe because uprobe might be shared with another
task.
I would resend the fixed patch unless someone comes up with something
else..

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Shorten constant names for EFI variable attributes

[Matthew Garrett]

On Thu, Jul 26, 2012 at 11:28:32AM -0600, Khalid Aziz wrote:

> I also do not believe that kernel must use the constant names
> mentioned in the specification especially when the name reaches 50
> characters. We can not get away from having to create aliases. Do
> you think having aliases in efi.h can cause mixed use of long names
> and short names in future code in the kernel? Can we address this by
> suggesting to future code authors that they should use the short
> names in their code? Should we consider inclusion of this patch in
> the kernel?

I'd be surprised if it were a problem - we should catch any of those 
cases in code review, or gate the aliases under #ifndef __KERNEL__

-- 
Matthew Garrett | mj...@srcf.ucam.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/

Re: [PATCH v8 0/7] power management patch set

[Kumar Gala]

On Jul 26, 2012, at 9:02 AM, Li Yang wrote:

> On Fri, Jul 20, 2012 at 8:42 PM, Zhao Chenhui
>  wrote:
>> Changes for v8:
>> * Separated the cpu hotplug patch into three patches, as follows
>> [PATCH v8 1/7] powerpc/smp: use a struct epapr_spin_table to replace macros
>> [PATCH v8 2/7] powerpc/smp: add generic_set_cpu_up() to set cpu_state as 
>> CPU_UP_PREPARE
>> [PATCH v8 4/7] powerpc/85xx: add HOTPLUG_CPU support
>> 
>> * Replaced magic numbers with macros in "[PATCH 5/7] powerpc/85xx: add sleep 
>> and deep sleep support"
>> 
>> * no change to the rest of the patch set
> 
> Hi Kumar,
> 
> How about picking about this series for 3.6?  The review seems to
> settle down for this revision.

Its too late for 3.6, but will look at queuing it up for 3.7.

> Hi Scott,
> 
> Thanks for the review comments provided.  We'd like to get the ACK
> from you for the series if you can.
> 
> Regards,
> Leo

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

Re: [PATCH 0/5] userns: convert some filesystems to kuid/kgid

[Aristeu Rozanski]

On Thu, Jul 26, 2012 at 10:24:41AM -0700, Eric W. Biederman wrote:
> Please see my userns-always-map-user-v41 branch.

d'oh. thanks Eric

-- 
Aristeu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Shorten constant names for EFI variable attributes

[Khalid Aziz]

On 07/23/2012 07:26 AM, Matthew Garrett wrote:

On Fri, Jul 20, 2012 at 03:10:56PM -0700, H. Peter Anvin wrote:

On 07/20/2012 03:08 PM, Khalid Aziz wrote:

Replace very long constants for EFI variable attributes
with shorter and more convenient names. Also create an
alias for the current longer names so as to not break
compatibility with current API since these constants
are used by userspace programs. This patch depends on
patch .

I think these some from the EFI specifcation, so NAK IMO.

 From the point of view of making efivars more readable, I'd certainly
prefer shorter constant names. Keeping an alias is necessary only
because it's an existing exposed interface. The specification doesn't
actually require the use of these specific names anywhere, and we've
taken a more relaxed attitude in other bits of the EFI code.


Matthew,

I also do not believe that kernel must use the constant names mentioned 
in the specification especially when the name reaches 50 characters. We 
can not get away from having to create aliases. Do you think having 
aliases in efi.h can cause mixed use of long names and short names in 
future code in the kernel? Can we address this by suggesting to future 
code authors that they should use the short names in their code? Should 
we consider inclusion of this patch in the kernel?


--
Khalid Aziz
khalid.a...@hp.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/

Re: [PATCH] video/smscufx: fix line counting in fb_write

[Florian Tobias Schandinat]

On 07/02/2012 09:25 PM, Alexander Holler wrote:
> Hi Florian,
> 
> sorry for the late answer.
> 
> Am 13.05.2012 14:47, schrieb Florian Tobias Schandinat:
>> Hi Alexander,
>>
>> On 04/21/2012 11:26 AM, Alexander Holler wrote:
>>> Hello,
>>>
>>> as for the patch for udlfb, I forgot to mention that this is a candidate
>>> for all stable trees 3.2 and above.
>>>
>>> Btw., the address of the maintainer doesn't seem to be valid anymore.
>>
>> it is better to cc me on patches to the framebuffer subsystem for such
>> cases. I don't have much free time so it's rare that I come around to
>> dig in the mailing list.
>>
>>>
>>> Regards,
>>>
>>> Alexander
>>>
>>> Am 21.04.2012 00:11, schrieb Alexander Holler:
 Line 0 and 1 were both written to line 0 (on the display) and all
 subsequent
 lines had an offset of -1. The result was that the last line on the
 display
 was never overwritten by writes to /dev/fbN.

 The origin of this bug seems to have been udlfb.

 Signed-off-by: Alexander Holler
>>>
>>> Cc: sta...@vger.kernel.org
>>
>> Patch looks good to me but can be made simpler.
>>
>>>
 ---
drivers/video/smscufx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
 index ccbfef5..1e1e2d2 100644
 --- a/drivers/video/smscufx.c
 +++ b/drivers/video/smscufx.c
 @@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_info *info,
 const char __user *buf,
result = fb_sys_write(info, buf, count, ppos);

if (result>  0) {
 -int start = max((int)(offset / info->fix.line_length) - 1, 0);
 +int start = max((int)(offset / info->fix.line_length), 0);
>>
>> the cast to int as well as the max is superfluous without the -1 as the
>> value can no longer be negative.
> 
> I had that impression too, but I wanted to change as less as possible,
> so I didn't had the need to check types and (their) sizes for possible
> overflows or such. I was lazy and just wanted to fix that one bug. ;)

Well, as this patch fixes a bug I applied it as is.

> 
>>
int lines = min((u32)((result / info->fix.line_length) + 1),
(u32)info->var.yres);



Best regards,

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

Re: [PATCH 0/5] userns: convert some filesystems to kuid/kgid

[Eric W. Biederman]

Aristeu Rozanski  writes:

> Hi Eric,
> On Wed, Jul 25, 2012 at 04:14:41PM -0700, Eric W. Biederman wrote:
>> Sorry no.  I have unfortunately been a bit out of it for the last few
>> weeks and I have patches to address this already in my development tree.
>
> what's the tree you're using for development? ebiederm/user-namespace.git at
> kernel.org doesn't have those changes.

Please see my userns-always-map-user-v41 branch.

Eric

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

Re: [PATCH v2] cx18: Declare MODULE_FIRMWARE usage

[Tim Gardner]

Missed a firmware file in cx18-av-firmware.c

rtg
--
Tim Gardner tim.gard...@canonical.com
>From 9b4be013f173efc12bb2776394bf6a5abb8725b6 Mon Sep 17 00:00:00 2001
From: Tim Gardner 
Date: Thu, 26 Jul 2012 11:03:51 -0600
Subject: [PATCH v2] cx18: Declare MODULE_FIRMWARE usage

Cc: Andy Walls 
Cc: Mauro Carvalho Chehab 
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Tim Gardner 
---
 drivers/media/video/cx18/cx18-av-firmware.c |2 ++
 drivers/media/video/cx18/cx18-driver.c  |1 +
 drivers/media/video/cx18/cx18-firmware.c|   10 --
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/cx18/cx18-av-firmware.c b/drivers/media/video/cx18/cx18-av-firmware.c
index 280aa4d..a34fd08 100644
--- a/drivers/media/video/cx18/cx18-av-firmware.c
+++ b/drivers/media/video/cx18/cx18-av-firmware.c
@@ -221,3 +221,5 @@ int cx18_av_loadfw(struct cx18 *cx)
 	release_firmware(fw);
 	return 0;
 }
+
+MODULE_FIRMWARE(FWFILE);
diff --git a/drivers/media/video/cx18/cx18-driver.c b/drivers/media/video/cx18/cx18-driver.c
index 7e5ffd6..c67733d 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
 
 module_init(module_start);
 module_exit(module_cleanup);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/video/cx18/cx18-firmware.c b/drivers/media/video/cx18/cx18-firmware.c
index b85c292..a1c1cec 100644
--- a/drivers/media/video/cx18/cx18-firmware.c
+++ b/drivers/media/video/cx18/cx18-firmware.c
@@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
 	cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14);  /* AVO */
 }
 
+#define CX18_CPU_FIRMWARE "v4l-cx23418-cpu.fw"
+#define CX18_APU_FIRMWARE "v4l-cx23418-apu.fw"
+
 int cx18_firmware_init(struct cx18 *cx)
 {
 	u32 fw_entry_addr;
@@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
 	cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
 	cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
 
-	sz = load_cpu_fw_direct("v4l-cx23418-cpu.fw", cx->enc_mem, cx);
+	sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx->enc_mem, cx);
 	if (sz <= 0)
 		return sz;
 
@@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
 	cx18_init_scb(cx);
 
 	fw_entry_addr = 0;
-	sz = load_apu_fw_direct("v4l-cx23418-apu.fw", cx->enc_mem, cx,
+	sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx->enc_mem, cx,
 &fw_entry_addr);
 	if (sz <= 0)
 		return sz;
@@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
 	cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
 	return 0;
 }
+
+MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
+MODULE_FIRMWARE(CX18_APU_FIRMWARE);
-- 
1.7.9.5

Re: [Xen-devel] [PATCH 02/24] xen/arm: hypercalls

[Stefano Stabellini]

On Thu, 26 Jul 2012, David Vrabel wrote:
> On 26/07/12 16:33, Stefano Stabellini wrote:
> > 
> > + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> > + * hypercall tag.
> 
> Is this number, 0xea1, assigned to Xen by some external body?

I am not aware of any "external body" that could assign us such a number
but it is specified in the Xen hypercall calling convention, documented
here:

http://xenbits.xensource.com/hg/xen-unstable.hg/file/663eb766cdde/xen/include/public/arch-arm.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git patches] libata updates

[Linus Torvalds]

On Wed, Jul 25, 2012 at 7:10 PM, Jeff Garzik  wrote:
>
> Thanks, so noted.  I guess if the merge gets more complex than something
> easily described in an email, that implies that maintainers should do more
> cross-coordination and maybe a merge tree.

It's fairly rare. It happens mostly with the arch trees for some
reason - the ARM tree used to be an unholy mess.

And then we have the small "oops, we didn't even notice" things when
some driver (or FS) interface changes, and we have a new driver/fs or
just extended an old one, and there's a subtle conflict. And people
miss those, and quite frankly, it's not a huge deal. We can fix it up
later. It's the "oh, I knew about this" cases where it's fixed up as a
separate commit I dislike.

And quite frankly, I really do a lot of merges, and over the history
of git we have not had all that many really complicated ones. I
commonly send people email saying "ok, this clashed, you need to
double-check my merge", but it's not common that they are really
problems.

So to a first approximation, I'd actually prefer that submaintainers
not care *at*all* about whether something clashes upstream or not. If
there are consistent and problematic clashes, that implies some deeper
problem, and the solution to that is not "let's pre-merge", but rather
more along the lines of "we're doing something wrong, maybe our
interfaces are crap, or our modularity is wrong, let's think about
it".

And for subsystems where we have had problems, it's actually really
nice if the maintainer sends me the unmerged "this is the work I've
done" tree, and then perhaps has a separate "xyzzy-merged" branch that
has a pre-merged version. For cases like that, I will do the merge
myself, but I'll actually double-check my merge against the maintainer
merge. And it's happened more than once that my merge has differed,
and _my_ merge is the correct one. The maintainer may know his code
better, but I know my merging. I do a ton of them.

For example, this week I've done 66 merges, and 15 of them had
conflicts. Of the 15, only two were interesting iirc, but even those
weren't really "problematic", they were just enough to trigger me to
send out emails to the maintainers about them. And I don't think your
libata merge would really have merited even that, apart from the small
semantic thing (which would also have been trivial with a oneliner
"heads up, check out the semantic change in xyz.c:abcdef()".

> What's the best way for libata to move forward, now that this hideous merge
> has been pushed out to the Well Known libata branches?  The
> pre-jgarzik-merge commit you would have pulled is
> dc7f71f486f4f5fa96f6dcf86833da020cde8a11 had my pull request been proper.

I'll take your merge, it's not like it's a huge problem. What I care
most about is the "flow", and I am making a stink just so that this
doesn't become a common issue. We have tons of ugly history, and I'm
not black-and-white - problems happen. Big deal. I just want to make
sure that they don't become systemic.

  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/

Re: [PATCH 0/5] userns: convert some filesystems to kuid/kgid

[Aristeu Rozanski]

Hi Eric,
On Wed, Jul 25, 2012 at 04:14:41PM -0700, Eric W. Biederman wrote:
> Sorry no.  I have unfortunately been a bit out of it for the last few
> weeks and I have patches to address this already in my development tree.

what's the tree you're using for development? ebiederm/user-namespace.git at
kernel.org doesn't have those changes.

Thanks

-- 
Aristeu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [next:akpm 129/309] net/core/sock.c:274:36: error: initializer element is not constant

[Tony Luck]

On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
 wrote:
>> Here is the line in sock.i:
>>
>> struct static_key memalloc_socks = ((struct static_key) { .enabled =
>> ((atomic_t) { (0) }) });
>
> The above line contains two compound literals.  It also uses a designated
> initializer to initialize the field enabled.  A compound literal is not a
> constant expression.

Seeing the same thing on ia64 building next-20120726.  Same fix works
for me ... so I'll steal this whole changelog and attributes.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] power_supply: Added support for power supply attribute sources

[Anton Vorontsov]

Hello Ramakrishna,

On Thu, Jul 26, 2012 at 08:47:24PM +0530, Ramakrishna Pallala wrote:
> On some platforms one driver(or HW chip) may not be able to provide all
> the necessary attributes of the power supply connected to the platform or
> may provide very limited info which can be used by core/primary drivers.
> 
> For example a temperature sensor chip placed near the battery can be used
> to report battery ambient temperature but it does not makes sense to register
> sensor driver with power supply class. Or even a ADC driver or platform
> driver may report power supply properties like voltage/current or charging
> status but registering all those driver with power supply class is not a
> practical or ideal approach.
> 
> This patch adds the generic support to register the drivers as power
> supply attribute(properties) sources and adds an interface to read
> these attributes from power supply class drivers.
> 
> If there are multiple attribute sources of the same type then caller has
> to do source selection by passing the source string in the query struct.
> 
> Signed-off-by: Ramakrishna Pallala 
> ---
[...]
> +extern int power_supply_attributes_register(struct device *parent,
> + struct power_supply_attr_source *psy_attr);

Can you please show some user of the new calls? If I understand
correctly, you're going to call these from sensing (ADC, or some
other) drivers, which would be very very wrong thing to do.

Thanks,

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

[PATCH] cx18: Declare MODULE_FIRMWARE usage

[Tim Gardner]

Cc: Andy Walls 
Cc: Mauro Carvalho Chehab 
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Tim Gardner 
---
 drivers/media/video/cx18/cx18-driver.c   |1 +
 drivers/media/video/cx18/cx18-firmware.c |   10 --
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/cx18/cx18-driver.c 
b/drivers/media/video/cx18/cx18-driver.c
index 7e5ffd6..c67733d 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
 
 module_init(module_start);
 module_exit(module_cleanup);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/video/cx18/cx18-firmware.c 
b/drivers/media/video/cx18/cx18-firmware.c
index b85c292..a1c1cec 100644
--- a/drivers/media/video/cx18/cx18-firmware.c
+++ b/drivers/media/video/cx18/cx18-firmware.c
@@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14);  /* AVO */
 }
 
+#define CX18_CPU_FIRMWARE "v4l-cx23418-cpu.fw"
+#define CX18_APU_FIRMWARE "v4l-cx23418-apu.fw"
+
 int cx18_firmware_init(struct cx18 *cx)
 {
u32 fw_entry_addr;
@@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
 
-   sz = load_cpu_fw_direct("v4l-cx23418-cpu.fw", cx->enc_mem, cx);
+   sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx->enc_mem, cx);
if (sz <= 0)
return sz;
 
@@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_init_scb(cx);
 
fw_entry_addr = 0;
-   sz = load_apu_fw_direct("v4l-cx23418-apu.fw", cx->enc_mem, cx,
+   sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx->enc_mem, cx,
&fw_entry_addr);
if (sz <= 0)
return sz;
@@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
return 0;
 }
+
+MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
+MODULE_FIRMWARE(CX18_APU_FIRMWARE);
-- 
1.7.9.5

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

Re: [PATCH 6/7] kdb: Mark safe commands as KDB_SAFE and KDB_SAFE_NO_ARGS

[Alan Cox]

> The following commands were marked as "safe":
> 
>   Clear Breakpoint
>   Enable Breakpoint
>   Disable Breakpoint
>   Display exception frame
>   Stack traceback

This is sufficient to steal cryptographic keys in many environments. In
fact you merely need two or three breakpoints and to log the order they
are hit through the crypto computation.

>   Display stack for process

Exposes all sorts of user data unless you mean just the call trace, in
which case it's still quite useful.

>   Display stack all processes

Ditto

>   Send a signal to a process

Like say sending SIGSTOP to security monitoring threads or the battery
manager on locked devices that rely on software battery management ?


It's an interesting idea but you need almost nothing to extract keys from
a system or to subvert it.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xconfig: Display dependency values in debug_info

[Randy Dunlap]

On 07/26/2012 09:19 AM, Salar Ali Mumtaz wrote:

> Hi.
> 
> Thanks for the quick reply.
> 
> This adds the current values to the dependencies in the debug_info, which you 
> get when you select "Show debug info" 
> from the popup you get after you right click. For some values, there is no 
> help available. For those, there is usually 
> information in the debug_info that is not displayed normally.
> 
> COMPAT_BINFMT_ELF
> 
> //This is added by debug_info
> type: boolean
> reverse dep: (IA32_EMULATION n && X86_64 n ) =n
> unknown property: symbol
> dep: ( COMPAT n && BINFMT_ELF y ) =n
> //This is added by debug_info
> 
> defined at fs/Kconfig.binfmt:26
> 
> There is no help available for this option.
> Symbol: COMPAT_BINFMT_ELF [=n]
> Type : boolean
> Selected by: IA32_EMULATION [=n] && X86_64 [=n]
> 
> Hope this helps.
> 


Yes, it does help.  Thanks.


For BINFMT_ELF (not your example of COMPAT_BINFMT_ELF)
in Linux 3.5, I see this:


BEFORE PATCH:

type: boolean
unknown property: symbol
dep: MMU && (BROKEN || !FRV)
prompt: Kernel support for ELF binaries
dep: MMU && (BROKEN || !FRV)
default: y
dep: MMU && (BROKEN || !FRV)

defined at fs/Kconfig.binfmt:1



AFTER PATCH:

type: boolean
unknown property: symbol
dep: ( MMU y && (BROKEN n || !FRV FRV) ) =y
prompt: Kernel support for ELF binaries
dep: ( MMU y && (BROKEN n || !FRV FRV) ) =y
default: y
dep: ( MMU y && (BROKEN n || !FRV FRV) ) =y

defined at fs/Kconfig.binfmt:1




The added y/n/m are clear, but the "!FRV FRV" is confusing,
isn't it?


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

Re: [Xen-devel] [PATCH 02/24] xen/arm: hypercalls

[David Vrabel]

On 26/07/12 16:33, Stefano Stabellini wrote:
> 
> + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> + * hypercall tag.

Is this number, 0xea1, assigned to Xen by some external body?

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

Re: [RFC PATCH 10/13] driver core: devres: introduce devres_for_each_res

[Ming Lei]

On Thu, Jul 26, 2012 at 12:25 AM, Borislav Petkov  wrote:
> On Wed, Jul 25, 2012 at 01:00:10AM +0800, Ming Lei wrote:
>> This patch introduces one devres API of devres_for_each_res
>> so that the device's driver can iterate each resource it has
>> interest in.
>>
>> The firmware loader will use the API to get each firmware name
>> from the device instance.
>>
>> Signed-off-by: Ming Lei 
>> ---
>>  drivers/base/devres.c  |   42 ++
>>  include/linux/device.h |3 +++
>>  2 files changed, 45 insertions(+)
>>
>> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
>> index 2360adb..8273ba5 100644
>> --- a/drivers/base/devres.c
>> +++ b/drivers/base/devres.c
>> @@ -144,6 +144,48 @@ EXPORT_SYMBOL_GPL(devres_alloc);
>>  #endif
>>
>>  /**
>> + * devres_for_each_res - Resource iterator
>> + * @dev: Device to iterate resource from
>> + * @release: Look for resources associated with this release function
>> + * @match: Match function (optional)
>> + * @match_data: Data for the match function
>> + * @fn: function to be called for each matched resource.
>> + *
>> + * Call @fn for each devres of @dev which is associated with @release
>> + * and for which @match returns 1.
>> + *
>> + * RETURNS:
>> + *   void
>> + */
>> +void devres_for_each_res(struct device *dev, dr_release_t release,
>> + dr_match_t match, void *match_data,
>> + void (*fn)(struct device *, void *))
>> +{
>> + struct devres_node *node;
>> + struct devres_node *tmp;
>> + unsigned long flags;
>> +
>> + if (!fn)
>> + return;
>> +
>> + spin_lock_irqsave(&dev->devres_lock, flags);
>> + list_for_each_entry_safe_reverse(node, tmp,
>> + &dev->devres_head, entry) {
>
> Why break this line?
>
> list_for_each_entry_safe_reverse(node, tmp, &dev->devres_head, entry) 
> {
>
> is perfectly fine.
>
>> + struct devres *dr = container_of(node, struct devres, node);
>> +
>> + if (node->release != release)
>> + continue;
>> + if (match && !match(dev, dr->data, match_data))
>> + continue;
>> + spin_unlock_irqrestore(&dev->devres_lock, flags);
>> + fn(dev, dr->data);
>> + spin_lock_irqsave(&dev->devres_lock, flags);
>> + }
>> + spin_unlock_irqrestore(&dev->devres_lock, flags);
>
> This looks strange. For the last node on the list, we're grabbing the
> lock and releasing it right after.
>
> Probably check whether node is the last element and only re-grab the
> lock if it isn't?

It is not necessary since the lock isn't held in hot path.

>
> And btw, don't we need to hold the ->devres_lock during the whole search
> like callers of find_dr do, for example?

Because I don't want to put more constraint on the 'fn' about lock use, memory
allocation flag(gfp)..., from the view of API's user.

In fact, there is problem wrt. releasing lock since add_dr may add new node
during releasing lock.

So I plan to just hold the lock to cover calling 'fn' in -v1 instead
of using rcu list
helpers, which may introduce a lot change on devres.

Anyway the callers can copy the resources interested into a temporary list
in 'fn' and handle it later, which may simplify devres_for_each_res and other
devres helpers a lot.

Also I will introduce another parameter of 'void *data' to 'fn' in -v1.

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] leds: triggers: send uevent when changing triggers

[Greg KH]

On Thu, Jul 26, 2012 at 01:03:11PM +0800, Bryan Wu wrote:
> Just one quick patch for my idea: emitting a uevent in sysfs_create_file().
> 
> --
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 00012e3..04da869 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -570,10 +570,14 @@ int sysfs_add_file(struct sysfs_dirent *dir_sd,
> const struct attribute *attr,
> 
>  int sysfs_create_file(struct kobject * kobj, const struct attribute * attr)
>  {
> +   int err = 0;
> +
> BUG_ON(!kobj || !kobj->sd || !attr);
> 
> -   return sysfs_add_file(kobj->sd, attr, SYSFS_KOBJ_ATTR);
> +   err = sysfs_add_file(kobj->sd, attr, SYSFS_KOBJ_ATTR);
> +   kobject_uevent(kobj, KOBJ_CHANGE);

That's a veritable flood of change events when a new kobject is created,
right?  It also created uevents for a device that has not told userspace
that it is even present, which could cause massive confusion, don't you
think?

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

Re: [Xen-devel] [PATCH 04/24] xen/arm: sync_bitops

[Konrad Rzeszutek Wilk]

On Thu, Jul 26, 2012 at 04:33:46PM +0100, Stefano Stabellini wrote:
> sync_bitops functions are equivalent to the SMP implementation of the
> original functions, independently from CONFIG_SMP being defined.

So why can't the code be changed to use that? Is it that
the _set_bit, _clear_bit, etc are not available with !CONFIG_SMP?

> 
> Signed-off-by: Stefano Stabellini 
> ---
>  arch/arm/include/asm/sync_bitops.h |   17 +
>  1 files changed, 17 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/include/asm/sync_bitops.h
> 
> diff --git a/arch/arm/include/asm/sync_bitops.h 
> b/arch/arm/include/asm/sync_bitops.h
> new file mode 100644
> index 000..d975092903
> --- /dev/null
> +++ b/arch/arm/include/asm/sync_bitops.h
> @@ -0,0 +1,17 @@
> +#ifndef __ASM_SYNC_BITOPS_H__
> +#define __ASM_SYNC_BITOPS_H__
> +
> +#include 
> +#include 
> +
> +#define sync_set_bit(nr, p)  _set_bit(nr, p)
> +#define sync_clear_bit(nr, p)_clear_bit(nr, p)
> +#define sync_change_bit(nr, p)   _change_bit(nr, p)
> +#define sync_test_and_set_bit(nr, p) _test_and_set_bit(nr, p)
> +#define sync_test_and_clear_bit(nr, p)   _test_and_clear_bit(nr, p)
> +#define sync_test_and_change_bit(nr, p)  _test_and_change_bit(nr, p)
> +#define sync_test_bit(nr, addr)  test_bit(nr, addr)
> +#define sync_cmpxchg cmpxchg
> +
> +
> +#endif
> -- 
> 1.7.2.5
> 
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> http://lists.xen.org/xen-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH 03/24] xen/arm: page.h definitions

[Konrad Rzeszutek Wilk]

On Thu, Jul 26, 2012 at 04:33:45PM +0100, Stefano Stabellini wrote:
> ARM Xen guests always use paging in hardware, like PV on HVM guests in
> the X86 world.

Nice, so no dealing with the P2M at all in the guest?

> 
> Signed-off-by: Stefano Stabellini 
> ---
>  arch/arm/include/asm/xen/page.h |   77 
> +++
>  1 files changed, 77 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/page.h
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> new file mode 100644
> index 000..6cfe9a1
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -0,0 +1,77 @@
> +#ifndef _ASM_ARM_XEN_PAGE_H
> +#define _ASM_ARM_XEN_PAGE_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

I don't if it makes such a difference, but putting the headers in sorted
order is sometimes nicer than just randomly.. But that might be just
me liking an orderly world nowadays :-)

> +
> +#define pfn_to_mfn(pfn)  (pfn)
> +#define phys_to_machine_mapping_valid(1)
> +#define mfn_to_pfn(mfn)  (mfn)
> +#define mfn_to_virt(m)   (__va(mfn_to_pfn(m) << 
> PAGE_SHIFT))
> +
> +#define pte_mfn  pte_pfn
> +#define mfn_pte  pfn_pte
> +
> +/* Xen machine address */
> +typedef struct xmaddr {
> + phys_addr_t maddr;
> +} xmaddr_t;
> +
> +/* Xen pseudo-physical address */
> +typedef struct xpaddr {
> + phys_addr_t paddr;
> +} xpaddr_t;
> +
> +#define XMADDR(x)((xmaddr_t) { .maddr = (x) })
> +#define XPADDR(x)((xpaddr_t) { .paddr = (x) })
> +
> +static inline xmaddr_t phys_to_machine(xpaddr_t phys)
> +{
> + unsigned offset = phys.paddr & ~PAGE_MASK;
> + return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
> +}
> +
> +static inline xpaddr_t machine_to_phys(xmaddr_t machine)
> +{
> + unsigned offset = machine.maddr & ~PAGE_MASK;
> + return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
> +}
> +/* VIRT <-> MACHINE conversion */
> +#define virt_to_machine(v)   (phys_to_machine(XPADDR(__pa(v
> +#define virt_to_pfn(v)  (PFN_DOWN(__pa(v)))
> +#define virt_to_mfn(v)   (pfn_to_mfn(virt_to_pfn(v)))
> +#define mfn_to_virt(m)   (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> +
> +static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
> +{
> + /* XXX: assuming it is mapped in the kernel 1:1 */
> + return virt_to_machine(vaddr);
> +}
> +
> +/* XXX: this shouldn't be here */

So why is it here?

> +static inline pte_t *lookup_address(unsigned long address, unsigned int 
> *level)
> +{
> + BUG();
> + return NULL;
> +}
> +
> +static inline int m2p_add_override(unsigned long mfn, struct page *page,
> + struct gnttab_map_grant_ref *kmap_op)
> +{
> + return 0;
> +}
> +
> +static inline int m2p_remove_override(struct page *page, bool clear_pte)
> +{
> + return 0;
> +}
> +
> +static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> +{
> + BUG();
> + return false;
> +}
> +#endif /* _ASM_ARM_XEN_PAGE_H */
> -- 
> 1.7.2.5
> 
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> http://lists.xen.org/xen-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cx25840: Declare MODULE_FIRMWARE usage

[Tim Gardner]

Cc: Mauro Carvalho Chehab 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Tim Gardner 
---
 drivers/media/video/cx25840/cx25840-firmware.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/cx25840/cx25840-firmware.c 
b/drivers/media/video/cx25840/cx25840-firmware.c
index 8150200..b3169f9 100644
--- a/drivers/media/video/cx25840/cx25840-firmware.c
+++ b/drivers/media/video/cx25840/cx25840-firmware.c
@@ -61,6 +61,10 @@ static void end_fw_load(struct i2c_client *client)
cx25840_write(client, 0x803, 0x03);
 }
 
+#define CX2388x_FIRMWARE "v4l-cx23885-avcore-01.fw"
+#define CX231xx_FIRMWARE "v4l-cx231xx-avcore-01.fw"
+#define CX25840_FIRMWARE "v4l-cx25840.fw"
+
 static const char *get_fw_name(struct i2c_client *client)
 {
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
@@ -68,10 +72,10 @@ static const char *get_fw_name(struct i2c_client *client)
if (firmware[0])
return firmware;
if (is_cx2388x(state))
-   return "v4l-cx23885-avcore-01.fw";
+   return CX2388x_FIRMWARE;
if (is_cx231xx(state))
-   return "v4l-cx231xx-avcore-01.fw";
-   return "v4l-cx25840.fw";
+   return CX231xx_FIRMWARE;
+   return CX25840_FIRMWARE;
 }
 
 static int check_fw_load(struct i2c_client *client, int size)
@@ -164,3 +168,8 @@ int cx25840_loadfw(struct i2c_client *client)
 
return check_fw_load(client, size);
 }
+
+MODULE_FIRMWARE(CX2388x_FIRMWARE);
+MODULE_FIRMWARE(CX231xx_FIRMWARE);
+MODULE_FIRMWARE(CX25840_FIRMWARE);
+
-- 
1.7.9.5

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

Re: [Xen-devel] [PATCH 02/24] xen/arm: hypercalls

[Konrad Rzeszutek Wilk]

On Thu, Jul 26, 2012 at 04:33:44PM +0100, Stefano Stabellini wrote:
> Use r12 to pass the hypercall number to the hypervisor.
> 
> We need a register to pass the hypercall number because we might not
> know it at compile time and HVC only takes an immediate argument.
> 
> Among the available registers r12 seems to be the best choice because it
> is defined as "intra-procedure call scratch register".
> 
> Use the ISS to pass an hypervisor specific tag.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  arch/arm/include/asm/xen/hypercall.h |   50 ++
>  arch/arm/xen/Makefile|2 +-
>  arch/arm/xen/hypercall.S |   65 
> ++
>  3 files changed, 116 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/hypercall.h
>  create mode 100644 arch/arm/xen/hypercall.S
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h 
> b/arch/arm/include/asm/xen/hypercall.h
> new file mode 100644
> index 000..4ac0624
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -0,0 +1,50 @@
> +/**
> + * hypercall.h
> + *
> + * Linux-specific hypervisor handling.
> + *
> + * Stefano Stabellini , Citrix, 2012
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the 
> Software,
> + * and to permit persons to whom the Software is furnished to do so, subject 
> to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> +#define _ASM_ARM_XEN_HYPERCALL_H
> +
> +#include 
> +
> +long privcmd_call(unsigned call, unsigned long a1,
> + unsigned long a2, unsigned long a3,
> + unsigned long a4, unsigned long a5);
> +int HYPERVISOR_xen_version(int cmd, void *arg);
> +int HYPERVISOR_console_io(int cmd, int count, char *str);
> +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int 
> count);
> +int HYPERVISOR_sched_op(int cmd, void *arg);
> +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> +int HYPERVISOR_physdev_op(int cmd, void *arg);
> +
> +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> index 0bad594..b9d6acc 100644
> --- a/arch/arm/xen/Makefile
> +++ b/arch/arm/xen/Makefile
> @@ -1 +1 @@
> -obj-y:= enlighten.o
> +obj-y:= enlighten.o hypercall.o
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> new file mode 100644
> index 000..038cc5b
> --- /dev/null
> +++ b/arch/arm/xen/hypercall.S
> @@ -0,0 +1,65 @@
> +/**
> + * hypercall.S
> + *
> + * Xen hypercall wrappers
> + *
> + * The Xen hypercall calling convention is very similar to the ARM
> + * procedure calling convention: the first paramter is passed in r0, the
> + * second in r1, the third in r2 and the third in r3. Considering that

I think you meant 'and the fourth in r3'.

So where does the similarity end?  Just in that we use r12?

> + * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
> + * in r4, differently from the procedure calling convention of using the

> + * stack for that case.
> + *
> + * The hypercall number is passed in r12.
> + *
> + * The return value is in r0.
> + *
> + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> + * hypercall tag.
> + *
> + * Stefano Stabellini , Citrix, 2012
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +
> +/* HVC 0xEA1 */
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define xen_hvc .word 0xf7e08ea1
> +#else

Re: [PATCH V7 2/4] (Updated) MIPS: Add board support for Loongson1B

[Ralf Baechle]

I replaced your old patch with the newly posted ones.

Thanks,

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

[PATCH v2] power_supply: Added support for power supply attribute sources

[Ramakrishna Pallala]

On some platforms one driver(or HW chip) may not be able to provide all
the necessary attributes of the power supply connected to the platform or
may provide very limited info which can be used by core/primary drivers.

For example a temperature sensor chip placed near the battery can be used
to report battery ambient temperature but it does not makes sense to register
sensor driver with power supply class. Or even a ADC driver or platform
driver may report power supply properties like voltage/current or charging
status but registering all those driver with power supply class is not a
practical or ideal approach.

This patch adds the generic support to register the drivers as power
supply attribute(properties) sources and adds an interface to read
these attributes from power supply class drivers.

If there are multiple attribute sources of the same type then caller has
to do source selection by passing the source string in the query struct.

Signed-off-by: Ramakrishna Pallala 
---
 Documentation/power/power_supply_class.txt |   30 ++
 drivers/power/power_supply_core.c  |   81 
 include/linux/power_supply.h   |   32 +++
 3 files changed, 143 insertions(+), 0 deletions(-)

diff --git a/Documentation/power/power_supply_class.txt 
b/Documentation/power/power_supply_class.txt
index c0f62ae..f8ceb45 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -130,6 +130,36 @@ while battery powers a load)
 TIME_TO_FULL - seconds left for battery to be considered full (i.e.
 while battery is charging)
 
+Power supply attribute sources
+~~
+On some platforms one driver(or HW chip) may not be able to provide all
+the necessary attributes of the power supply connected to the platform.
+
+For example a temperature sensor chip placed near the battery can be used
+to report battery ambient temperature but it does not makes sense to register
+sensor driver with power supply class. Or even a ADC driver or platform
+driver may report power supply properties like voltage/current or charging
+status but registering all those driver with power supply class is not a
+practical or ideal approach.
+
+Power supply subsystem provides an interface to register and report about
+these power supply attributes to the primary driver which is registered
+with power supply class.
+
+Power supply attribute source driver can use the following functions to
+register/unregister as attributes source.
+
+int power_supply_attributes_register(struct device *parent,
+   struct power_supply_attr_source *psy_attr);
+
+void power_supply_attributes_unregister(
+   struct power_supply_attr_source *psy_attr);
+
+Power supply class driver(consumer driver) which needs to get
+power supply attributes can call the following function.
+
+int power_supply_get_external_attr(
+   struct power_supply_attr_query *query);
 
 Battery <-> external power supply interaction
 ~
diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index ff990d2..a4b52f4 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,8 @@ EXPORT_SYMBOL_GPL(power_supply_class);
 
 static struct device_type power_supply_dev_type;
 
+static LIST_HEAD(list_head_source_attr);
+
 static int __power_supply_changed_work(struct device *dev, void *data)
 {
struct power_supply *psy = (struct power_supply *)data;
@@ -164,6 +167,37 @@ int power_supply_powers(struct power_supply *psy, struct 
device *dev)
 }
 EXPORT_SYMBOL_GPL(power_supply_powers);
 
+int power_supply_get_external_attr(struct power_supply_attr_query *query)
+{
+   struct list_head *list;
+   struct power_supply_attr_source *psy_attr;
+   int ret = -ENODEV;
+
+   if (!query || list_empty(&list_head_source_attr))
+   return -EINVAL;
+
+   list_for_each(list, &list_head_source_attr) {
+   psy_attr = list_entry(list,
+   struct power_supply_attr_source, attr_pool);
+
+   if (psy_attr->type != query->type)
+   continue;
+   if (query->src_name && strcmp(query->src_name,
+   psy_attr->name))
+   continue;
+
+   ret = psy_attr->get_property(psy_attr,
+   query->property, &query->res);
+   if (ret < 0)
+   continue;
+   else
+   break;
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(power_supply_get_external_attr);
+
 static void power_supply_dev_release(struct device *dev)
 {
pr_debug("device: '%s': %s\n", dev_name(dev), __func__);
@@ 

Re: [Xen-devel] [PATCH 01/24] arm: initial Xen support

[Konrad Rzeszutek Wilk]

On Thu, Jul 26, 2012 at 04:33:43PM +0100, Stefano Stabellini wrote:
> - Basic hypervisor.h and interface.h definitions.
> - Skelethon enlighten.c, set xen_start_info to an empty struct.

Skeleton

> - Do not limit xen_initial_domain to PV guests.

Better wording: Make xen_initial_domain dependent on the SIF_PRIVILIGED_BIT.

Which reminds me - what about PV guests that do PCI passthrough. Aren't
they "more" priviligied than normal PV guests? Or not really?
> 
> The new code only compiles when CONFIG_XEN is set, that is going to be
> added to arch/arm/Kconfig in a later patch.

s/later patch//

> 
> Signed-off-by: Stefano Stabellini 
> ---
>  arch/arm/Makefile |1 +
>  arch/arm/include/asm/hypervisor.h |6 +++
>  arch/arm/include/asm/xen/hypervisor.h |   19 ++
>  arch/arm/include/asm/xen/interface.h  |   64 
> +
>  arch/arm/xen/Makefile |1 +
>  arch/arm/xen/enlighten.c  |   35 ++
>  include/xen/xen.h |2 +-
>  7 files changed, 127 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/include/asm/hypervisor.h
>  create mode 100644 arch/arm/include/asm/xen/hypervisor.h
>  create mode 100644 arch/arm/include/asm/xen/interface.h
>  create mode 100644 arch/arm/xen/Makefile
>  create mode 100644 arch/arm/xen/enlighten.c
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 0298b00..70aaa82 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -246,6 +246,7 @@ endif
>  core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/
>  core-$(CONFIG_FPE_FASTFPE)   += $(FASTFPE_OBJ)
>  core-$(CONFIG_VFP)   += arch/arm/vfp/
> +core-$(CONFIG_XEN)   += arch/arm/xen/
>  
>  # If we have a machine-specific directory, then include it in the build.
>  core-y   += arch/arm/kernel/ arch/arm/mm/ 
> arch/arm/common/
> diff --git a/arch/arm/include/asm/hypervisor.h 
> b/arch/arm/include/asm/hypervisor.h
> new file mode 100644
> index 000..b90d9e5
> --- /dev/null
> +++ b/arch/arm/include/asm/hypervisor.h
> @@ -0,0 +1,6 @@
> +#ifndef _ASM_ARM_HYPERVISOR_H
> +#define _ASM_ARM_HYPERVISOR_H
> +
> +#include 
> +
> +#endif
> diff --git a/arch/arm/include/asm/xen/hypervisor.h 
> b/arch/arm/include/asm/xen/hypervisor.h
> new file mode 100644
> index 000..d7ab99a
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/hypervisor.h
> @@ -0,0 +1,19 @@
> +#ifndef _ASM_ARM_XEN_HYPERVISOR_H
> +#define _ASM_ARM_XEN_HYPERVISOR_H
> +
> +extern struct shared_info *HYPERVISOR_shared_info;
> +extern struct start_info *xen_start_info;
> +
> +/* Lazy mode for batching updates / context switch */
> +enum paravirt_lazy_mode {
> + PARAVIRT_LAZY_NONE,
> + PARAVIRT_LAZY_MMU,
> + PARAVIRT_LAZY_CPU,
> +};
> +
> +static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
> +{
> + return PARAVIRT_LAZY_NONE;
> +}
> +
> +#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
> diff --git a/arch/arm/include/asm/xen/interface.h 
> b/arch/arm/include/asm/xen/interface.h
> new file mode 100644
> index 000..6c3ab59
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -0,0 +1,64 @@
> +/**
> + * Guest OS interface to ARM Xen.
> + *
> + * Stefano Stabellini , Citrix, 2011

2012

> + */
> +
> +#ifndef _ASM_ARM_XEN_INTERFACE_H
> +#define _ASM_ARM_XEN_INTERFACE_H
> +
> +#include 
> +
> +#define __DEFINE_GUEST_HANDLE(name, type) \
> + typedef type * __guest_handle_ ## name
> +
> +#define DEFINE_GUEST_HANDLE_STRUCT(name) \
> + __DEFINE_GUEST_HANDLE(name, struct name)
> +#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
> +#define GUEST_HANDLE(name)__guest_handle_ ## name
> +
> +#define set_xen_guest_handle(hnd, val)   \
> + do {\
> + if (sizeof(hnd) == 8)   \
> + *(uint64_t *)&(hnd) = 0;\
> + (hnd) = val;\
> + } while (0)
> +
> +#ifndef __ASSEMBLY__
> +/* Guest handles for primitive C types. */
> +__DEFINE_GUEST_HANDLE(uchar, unsigned char);
> +__DEFINE_GUEST_HANDLE(uint,  unsigned int);
> +__DEFINE_GUEST_HANDLE(ulong, unsigned long);
> +DEFINE_GUEST_HANDLE(char);
> +DEFINE_GUEST_HANDLE(int);
> +DEFINE_GUEST_HANDLE(long);
> +DEFINE_GUEST_HANDLE(void);
> +DEFINE_GUEST_HANDLE(uint64_t);
> +DEFINE_GUEST_HANDLE(uint32_t);
> +
> +/* Maximum number of virtual CPUs in multi-processor guests. */
> +#define MAX_VIRT_CPUS 1
> +
> +struct arch_vcpu_info { };
> +struct arch_shared_info { };
> +
> +/* XXX: Move pvclock definitions some place arch independent */
> +struct pvclock_vcpu_time_info {
> + u32   version;
> + u32   pad0;
> + u64   tsc_timestamp;
> + u64   system_time;
> + u32   tsc_to_system_mul;
> + s8tsc_shift;
> + u8flags;
> + u8pad[2];
> +} 

Re: [PATCH RESEND v8 2/2] mmc: card: Adding support for sanitize in eMMC 4.5

[S, Venkatraman]

On Wed, Jul 25, 2012 at 5:01 PM, Yaniv Gardi  wrote:
> This feature delete the unmap memory region of the eMMC card,
> by writing to a specific register in the EXT_CSD
> unmap region is the memory region that were previously deleted
> (by erase, trim or discard operation)
>
> Signed-off-by: Yaniv Gardi 
>
> ---
>  drivers/mmc/card/block.c |   72 
> +-
>  drivers/mmc/card/queue.c |   10 ++-
>  include/linux/mmc/host.h |1 +
>  3 files changed, 62 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index f1c84de..c45ec9f 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -860,10 +860,10 @@ static int mmc_blk_issue_secdiscard_rq(struct mmc_queue 
> *mq,
>  {
> struct mmc_blk_data *md = mq->data;
> struct mmc_card *card = md->queue.card;
> -   unsigned int from, nr, arg, trim_arg, erase_arg;
> +   unsigned int from, nr, arg;
> int err = 0, type = MMC_BLK_SECDISCARD;
>
> -   if (!(mmc_can_secure_erase_trim(card) || mmc_can_sanitize(card))) {
> +   if (!(mmc_can_secure_erase_trim(card))) {
> err = -EOPNOTSUPP;
> goto out;
> }
> @@ -871,23 +871,10 @@ static int mmc_blk_issue_secdiscard_rq(struct mmc_queue 
> *mq,
> from = blk_rq_pos(req);
> nr = blk_rq_sectors(req);
>
> -   /* The sanitize operation is supported at v4.5 only */
> -   if (mmc_can_sanitize(card)) {
> -   erase_arg = MMC_ERASE_ARG;
> -   trim_arg = MMC_TRIM_ARG;
> -   } else {
> -   erase_arg = MMC_SECURE_ERASE_ARG;
> -   trim_arg = MMC_SECURE_TRIM1_ARG;
> -   }
> -
> -   if (mmc_erase_group_aligned(card, from, nr))
> -   arg = erase_arg;
> -   else if (mmc_can_trim(card))
> -   arg = trim_arg;
> -   else {
> -   err = -EINVAL;
> -   goto out;
> -   }
> +   if (mmc_can_trim(card) && !mmc_erase_group_aligned(card, from, nr))
> +   arg = MMC_SECURE_TRIM1_ARG;
> +   else
> +   arg = MMC_SECURE_ERASE_ARG;
>  retry:
> if (card->quirks & MMC_QUIRK_INAND_CMD38) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> @@ -937,6 +924,46 @@ out:
> return err ? 0 : 1;
>  }
>
> +static int mmc_blk_issue_sanitize_rq(struct mmc_queue *mq,
> + struct request *req)
> +{
> +   struct mmc_blk_data *md = mq->data;
> +   struct mmc_card *card = md->queue.card;
> +   int err = 0;
> +
> +   BUG_ON(!card);
> +   BUG_ON(!card->host);
> +
> +   if (!(mmc_can_sanitize(card) &&
> +(card->host->caps2 & MMC_CAP2_SANITIZE))) {
> +   pr_warning("%s: %s - SANITIZE is not supported\n",
> +  mmc_hostname(card->host), __func__);
> +   err = -EOPNOTSUPP;
> +   goto out;
> +   }
> +
> +   pr_debug("%s: %s - SANITIZE IN PROGRESS...\n",
> +   mmc_hostname(card->host), __func__);
> +
> +   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> +EXT_CSD_SANITIZE_START, 1, 0);
> +
Everything else seems to be good overall. But you need some sort of timeout
implementation and handling for SANTIZE. It's not interrupted to
provide way for other commands,
as generic CMD6 timeout doesn't apply.
Currently, the device can be easily DOS'ed by just issuing the IOCTL repeatedly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] hpsa: use ioremap_nocache instead of ioremap

[Stephen M. Cameron]

From: Stephen M. Cameron 

I think ioremap() ends up being equivalent to ioremap_nocache
by default, but we should signal our intent that these mappings
should be non-cacheable.

Signed-off-by: Stephen M. Cameron 
---
 drivers/scsi/hpsa.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 415db96..5ed5859 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -3337,7 +3337,8 @@ static void __iomem *remap_pci_mem(ulong base, ulong size)
 {
ulong page_base = ((ulong) base) & PAGE_MASK;
ulong page_offs = ((ulong) base) - page_base;
-   void __iomem *page_remapped = ioremap(page_base, page_offs + size);
+   void __iomem *page_remapped = ioremap_nocache(page_base,
+   page_offs + size);
 
return page_remapped ? (page_remapped + page_offs) : NULL;
 }

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

[PATCH 0/3] hpsa patches for July 2012

[Stephen M. Cameron]

Only one important bug fix, we should use LUN reset rather
than target reset in the reset error handler as Smart Array
logical drives don't actually support target reset and end up
getting offlined, which is pretty bad.  I had done my reset
testing with tape drives only, which turns out to have been
a stupid thing to do.

The other two patches are very minor.

---

Stephen M. Cameron (3):
  hpsa: Use LUN reset instead of target reset
  hpsa: fix incorrect abort diagnostic message
  hpsa: use ioremap_nocache instead of ioremap 


 drivers/scsi/hpsa.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

-- 
-- steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] hpsa: fix incorrect abort diagnostic message

[Stephen M. Cameron]

From: Stephen M. Cameron 

In the abort handler, when asked to abort a command which
is not known to the driver, SUCCESS is returned, but the
diagnostic message incorrectly indicates the abort failed.

Signed-off-by: Stephen M. Cameron 
---
 drivers/scsi/hpsa.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 015a6c8..415db96 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -2609,7 +2609,7 @@ static int hpsa_eh_abort_handler(struct scsi_cmnd *sc)
/* not in reqQ, if also not in cmpQ, must have already completed */
found = hpsa_find_cmd_in_queue(h, sc, &h->cmpQ);
if (!found)  {
-   dev_dbg(&h->pdev->dev, "%s Request FAILED (not known to 
driver).\n",
+   dev_dbg(&h->pdev->dev, "%s Request SUCCEEDED (not known to 
driver).\n",
msg);
return SUCCESS;
}

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

[PATCH 1/3] hpsa: Use LUN reset instead of target reset

[Stephen M. Cameron]

From: Stephen M. Cameron 

It turns out Smart Array logical drives do not support target
reset and when the target reset fails, the logical drive will
be taken off line.  Symptoms look like this:

hpsa :03:00.0: Abort request on C1:B0:T0:L0
hpsa :03:00.0: resetting device 1:0:0:0
hpsa :03:00.0: cp 880037c56000 is reported invalid (probably means 
target device no longer present)
hpsa :03:00.0: resetting device failed.
sd 1:0:0:0: Device offlined - not ready after error recovery
sd 1:0:0:0: rejecting I/O to offline device
EXT3-fs error (device sdb1): read_block_bitmap:

LUN reset is supported though, and is what we should be using.
Target reset is also disruptive in shared SAS situations,
for example, an external MSA1210m which does support target
reset attached to Smart Arrays in multiple hosts -- a target
reset from one host is disruptive to other hosts as all LUNs
on the target will be reset and will abort all outstanding i/os
back to all the attached hosts.  So we should use LUN reset,
not target reset.

Tested this with Smart Array logical drives and with tape drives.
Not sure how this bug survived since 2009, except it must be very
rare for a Smart Array to require more than 30s to complete a request.

Signed-off-by: Stephen M. Cameron 
Cc: sta...@vger.kernel.org
---
 drivers/scsi/hpsa.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 796482b..015a6c8 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -3265,7 +3265,7 @@ static void fill_cmd(struct CommandList *c, u8 cmd, 
struct ctlr_info *h,
c->Request.Timeout = 0; /* Don't time out */
memset(&c->Request.CDB[0], 0, sizeof(c->Request.CDB));
c->Request.CDB[0] =  cmd;
-   c->Request.CDB[1] = 0x03;  /* Reset target above */
+   c->Request.CDB[1] = HPSA_RESET_TYPE_LUN;
/* If bytes 4-7 are zero, it means reset the */
/* LunID device */
c->Request.CDB[4] = 0x00;

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

Re: [Xen-devel] [PATCH] xen/p2m: Check __brk_limit before allocating.

[Konrad Rzeszutek Wilk]

On Thu, Jul 26, 2012 at 08:53:02AM +0100, Ian Campbell wrote:
> On Tue, 2012-07-24 at 16:23 -0400, Konrad Rzeszutek Wilk wrote:
> > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> > index 64effdc..b5bb26c 100644
> > --- a/arch/x86/xen/p2m.c
> > +++ b/arch/x86/xen/p2m.c
> > @@ -498,7 +498,14 @@ static bool alloc_p2m(unsigned long pfn)
> >  
> > return true;
> >  }
> > -
> > +#include 
> > +bool __init can_extend_brk()
> > +{
> > +   /* Always reserve one for the DMI extend_brk call. */
> 
> That seems a bit fragile, what if someone adds something else or the
> link order changes etc?
> 
> Can't we just have a variant of extend_brk which returns NULL instead of
> BUG_ON and do error checking?
> 
> Or even just change extend_brk and push the BUG_ONs out to the callers
> -- there aren't that many of them.

Good thinking. Let me redo it that way and see get x86 folks input.
> 
> Ian.
> -- 
> Ian Campbell
> 
> 
> Most people in this society who aren't actively mad are, at best,
> reformed or potential lunatics.
>   -- Susan Sontag
> 
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> http://lists.xen.org/xen-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usbduxsigma: Declare MODULE_FIRMWARE usage

[Tim Gardner]

Cc: Ian Abbott 
Cc: Mori Hess 
Cc: Greg Kroah-Hartman 
Cc: Bernd Porr 
Cc: Dan Carpenter 
Cc: H Hartley Sweeten 
Cc: de...@driverdev.osuosl.org
Signed-off-by: Tim Gardner 
---
 drivers/staging/comedi/drivers/usbduxsigma.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/usbduxsigma.c 
b/drivers/staging/comedi/drivers/usbduxsigma.c
index 465afbd..816c3a1 100644
--- a/drivers/staging/comedi/drivers/usbduxsigma.c
+++ b/drivers/staging/comedi/drivers/usbduxsigma.c
@@ -63,6 +63,7 @@ Status: testing
 #include "../comedidev.h"
 
 #define BOARDNAME "usbduxsigma"
+#define FIRMWARE "usbduxsigma_firmware.bin"
 
 /* timeout for the USB-transfer in ms*/
 #define BULK_TIMEOUT 1000
@@ -2588,7 +2589,7 @@ static int usbduxsigma_probe(struct usb_interface 
*uinterf,
 
ret = request_firmware_nowait(THIS_MODULE,
  FW_ACTION_HOTPLUG,
- "usbduxsigma_firmware.bin",
+ FIRMWARE,
  &udev->dev,
  GFP_KERNEL,
  usbduxsub + index,
@@ -2865,3 +2866,4 @@ module_exit(exit_usbduxsigma);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(FIRMWARE);
-- 
1.7.9.5

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

Registration Link for Kernel Summit with Plumber add on will be sent out soon

[James Bottomley]

For those of you who are worrying, the real registration link for the
kernel summit (as opposed to the google form to count who's going) will
be sent out soon.  This link will also allow you to register for
Plumbers for $200 (which won't change even after the late registration
deadline).

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usbdux: Declare MODULE_FIRMWARE usage

[Tim Gardner]

Cc: Ian Abbott 
Cc: Mori Hess 
Cc: Greg Kroah-Hartman 
Cc: H Hartley Sweeten 
Cc: de...@driverdev.osuosl.org
Signed-off-by: Tim Gardner 
---
 drivers/staging/comedi/drivers/usbdux.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/usbdux.c 
b/drivers/staging/comedi/drivers/usbdux.c
index 13d9fd3..20679c5 100644
--- a/drivers/staging/comedi/drivers/usbdux.c
+++ b/drivers/staging/comedi/drivers/usbdux.c
@@ -102,6 +102,7 @@ sampling rate. If you sample two channels you get 4kHz and 
so on.
 #include "../comedidev.h"
 
 #define BOARDNAME "usbdux"
+#define FIRMWARE "usbdux_firmware.bin"
 
 /* timeout for the USB-transfer in ms*/
 #define BULK_TIMEOUT 1000
@@ -2577,7 +2578,7 @@ static int usbduxsub_probe(struct usb_interface *uinterf,
 
ret = request_firmware_nowait(THIS_MODULE,
  FW_ACTION_HOTPLUG,
- "usbdux_firmware.bin",
+ FIRMWARE,
  &udev->dev,
  GFP_KERNEL,
  usbduxsub + index,
@@ -2887,3 +2888,4 @@ module_exit(exit_usbdux);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(FIRMWARE);
-- 
1.7.9.5

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

Re: linux-next: Tree for July 26 (vfio)

[Alex Williamson]

On Thu, 2012-07-26 at 08:43 -0700, Randy Dunlap wrote:
> On 07/25/2012 10:04 PM, Stephen Rothwell wrote:
> 
> > Hi all,
> > 
> > 
> > Changes since 20120725:
> > 
> > 
> 
> 
> on x86_64:
> 
>   CC [M]  drivers/vfio/pci/vfio_pci_intrs.o
> drivers/vfio/pci/vfio_pci_intrs.c: In function 'virqfd_enable':
> drivers/vfio/pci/vfio_pci_intrs.c:142:2: error: implicit declaration of 
> function 'eventfd_fget'
> drivers/vfio/pci/vfio_pci_intrs.c:142:7: warning: assignment makes pointer 
> from integer without a cast
> drivers/vfio/pci/vfio_pci_intrs.c:148:2: error: implicit declaration of 
> function 'eventfd_ctx_fileget'
> drivers/vfio/pci/vfio_pci_intrs.c:148:6: warning: assignment makes pointer 
> from integer without a cast
> make[4]: *** [drivers/vfio/pci/vfio_pci_intrs.o] Error 1

Thanks!  vfio-pci is useless without CONFIG_EVENTFD so I've added that
to the Kconfig depends.  Should be fixed in tomorrows tree.  Thanks,

Alex


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

[GIT PULL (PATCH 0/4) v2] VFIO driver for v3.6

[Alex Williamson]

On Wed, 2012-07-25 at 08:53 -0600, Alex Williamson wrote:
> Hi Linus,
> 
> This series includes the VFIO userspace driver interface for the
> 3.6 kernel merge window.  This driver is intended to provide a
> secure interface for device access using IOMMU protection for
> applications like assignment of physical devices to virtual
> machines.  Qemu will be the first user of this interface, enabling
> assignment of PCI devices to Qemu guests.  This interface is
> intended to eventually replace the x86-specific assignment mechanism
> currently available in KVM.  This interface has the advantage of
> being more secure, by working with IOMMU groups to ensure device
> isolation and providing it's own filtered resource access mechanism,
> and also more flexible, in not being x86 or KVM specific (extensions
> to enable POWER are already working).
> 
> As a new driver, I'm including both the individual patches in email,
> as well as a branch to pull from:
> 
> git://github.com/awilliam/linux-vfio.git for-linus
> 
> This driver is originally the work of Tom Lyon, but has since been
> handed over to me and gone through a complete overhaul thanks to the
> input from David Gibson, Ben Herrenschmidt, Chris Wright, Joerg
> Roedel, and others.  This driver has been available in linux-next for
> the last month.  Thanks,

randconfig testing in next found a dependency issue that I've fix in the
for-linus branch above.  Change from v1 is:

diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index cc7db62..5980758 100644
--- a/drivers/vfio/pci/Kconfig
+++ b/drivers/vfio/pci/Kconfig
@@ -1,6 +1,6 @@
 config VFIO_PCI
tristate "VFIO support for PCI devices"
-   depends on VFIO && PCI
+   depends on VFIO && PCI && EVENTFD
help
  Support for the PCI VFIO bus driver.  This is required to make
  use of PCI drivers using the VFIO framework.

If anyone wants a full resend of v2 to the list with this change, please
let me know.  Thanks,

Alex

> ---
> 
> Alex Williamson (4):
>   vfio: Add PCI device driver
>   vfio: Type1 IOMMU implementation
>   vfio: Add documentation
>   vfio: VFIO core
> 
> 
>  Documentation/ioctl/ioctl-number.txt |1 
>  Documentation/vfio.txt   |  314 +++
>  MAINTAINERS  |8 
>  drivers/Kconfig  |2 
>  drivers/Makefile |1 
>  drivers/vfio/Kconfig |   16 
>  drivers/vfio/Makefile|3 
>  drivers/vfio/pci/Kconfig |8 
>  drivers/vfio/pci/Makefile|4 
>  drivers/vfio/pci/vfio_pci.c  |  579 +
>  drivers/vfio/pci/vfio_pci_config.c   | 1540 
> ++
>  drivers/vfio/pci/vfio_pci_intrs.c|  740 
>  drivers/vfio/pci/vfio_pci_private.h  |   91 ++
>  drivers/vfio/pci/vfio_pci_rdwr.c |  269 ++
>  drivers/vfio/vfio.c  | 1420 +++
>  drivers/vfio/vfio_iommu_type1.c  |  753 +
>  include/linux/vfio.h |  445 ++
>  17 files changed, 6194 insertions(+)
>  create mode 100644 Documentation/vfio.txt
>  create mode 100644 drivers/vfio/Kconfig
>  create mode 100644 drivers/vfio/Makefile
>  create mode 100644 drivers/vfio/pci/Kconfig
>  create mode 100644 drivers/vfio/pci/Makefile
>  create mode 100644 drivers/vfio/pci/vfio_pci.c
>  create mode 100644 drivers/vfio/pci/vfio_pci_config.c
>  create mode 100644 drivers/vfio/pci/vfio_pci_intrs.c
>  create mode 100644 drivers/vfio/pci/vfio_pci_private.h
>  create mode 100644 drivers/vfio/pci/vfio_pci_rdwr.c
>  create mode 100644 drivers/vfio/vfio.c
>  create mode 100644 drivers/vfio/vfio_iommu_type1.c
>  create mode 100644 include/linux/vfio.h



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

Re: [PATCH 07/21] ASoC: io: Prevent use of regmap if request fails

[Lee Jones]

On 26/07/12 16:25, Mark Brown wrote:

On Thu, Jul 26, 2012 at 04:23:33PM +0100, Lee Jones wrote:


What's my 'control data'? It's not used in the original codec patch.



The old way wants to go:



snd_soc_update_bits() -> snd_soc_read() -> ab8500_codec_read_reg()



When then calls back into the abx500.



So what 'control data' should I be storing in the codec struct?


You're supposed to use it for the data you use to call back into the
underlying I/O code.


I don't understand. What 'data'?

Surely if .read and .write are populated in 'struct 
snd_soc_codec_driver', then it should just call back into those?


--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] usbduxfast: Declare MODULE_FIRMWARE usage

[Tim Gardner]

Cc: Ian Abbott 
Cc: Mori Hess 
Cc: Greg Kroah-Hartman 
Cc: H Hartley Sweeten 
Cc: Ravishankar Karkala Mallikarjunayya 
Cc: de...@driverdev.osuosl.org
Signed-off-by: Tim Gardner 
---
 drivers/staging/comedi/drivers/usbduxfast.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/usbduxfast.c 
b/drivers/staging/comedi/drivers/usbduxfast.c
index 7b1d21a..5f41d49 100644
--- a/drivers/staging/comedi/drivers/usbduxfast.c
+++ b/drivers/staging/comedi/drivers/usbduxfast.c
@@ -53,6 +53,7 @@
 #define DRIVER_AUTHOR "Bernd Porr, berndp...@f2s.com"
 #define DRIVER_DESC "USB-DUXfast, berndp...@f2s.com"
 #define BOARDNAME "usbduxfast"
+#define FIRMWARE "usbduxfast_firmware.bin"
 
 /*
  * timeout for the USB-transfer
@@ -1578,7 +1579,7 @@ static int usbduxfastsub_probe(struct usb_interface 
*uinterf,
 
ret = request_firmware_nowait(THIS_MODULE,
  FW_ACTION_HOTPLUG,
- "usbduxfast_firmware.bin",
+ FIRMWARE,
  &udev->dev,
  GFP_KERNEL,
  usbduxfastsub + index,
@@ -1804,3 +1805,4 @@ module_exit(exit_usbduxfast);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(FIRMWARE);
-- 
1.7.9.5

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

Re: [PATCH] mm: hugetlbfs: Close race during teardown of hugetlbfs shared page tables v2

[Larry Woodman]

On 07/20/2012 09:49 AM, Mel Gorman wrote:

+retry:
mutex_lock(&mapping->i_mmap_mutex);
vma_prio_tree_foreach(svma,&iter,&mapping->i_mmap, idx, idx) {
if (svma == vma)
continue;
+   if (svma->vm_mm == vma->vm_mm)
+   continue;
+
+   /*
+* The target mm could be in the process of tearing down
+* its page tables and the i_mmap_mutex on its own is
+* not sufficient. To prevent races against teardown and
+* pagetable updates, we acquire the mmap_sem and pagetable
+* lock of the remote address space. down_read_trylock()
+* is necessary as the other process could also be trying
+* to share pagetables with the current mm. In the fork
+* case, we are already both mm's so check for that
+*/
+   if (locked_mm != svma->vm_mm) {
+   if (!down_read_trylock(&svma->vm_mm->mmap_sem)) {
+   mutex_unlock(&mapping->i_mmap_mutex);
+   goto retry;
+   }
+   smmap_sem =&svma->vm_mm->mmap_sem;
+   }
+
+   spage_table_lock =&svma->vm_mm->page_table_lock;
+   spin_lock_nested(spage_table_lock, SINGLE_DEPTH_NESTING);

saddr = page_table_shareable(svma, vma, addr, idx);
if (saddr) {


Hi Mel, FYI I tried this and ran into a problem.  When there are 
multiple processes
in huge_pmd_share() just faulting in the same i_map they all have their 
mmap_sem

down for write so the down_read_trylock(&svma->vm_mm->mmap_sem) never
succeeds.  What am I missing?

Thanks, Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 23/24] hvc_xen: allow dom0_write_console for HVM guests

[Stefano Stabellini]

On ARM all guests are HVM guests, including Dom0.
Allow dom0_write_console to be called by an HVM domain.

Signed-off-by: Stefano Stabellini 
---
 drivers/tty/hvc/hvc_xen.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 3c04fb8..949edc2 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -616,12 +616,9 @@ static void xenboot_write_console(struct console *console, 
const char *string,
unsigned int linelen, off = 0;
const char *pos;
 
-   if (!xen_pv_domain())
-   return;
-
dom0_write_console(0, string, len);
 
-   if (xen_initial_domain())
+   if (!xen_pv_domain())
return;
 
domU_write_console(0, "(early) ", 8);
-- 
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 15/24] xen/arm: receive Xen events on ARM

[Stefano Stabellini]

Compile events.c on ARM.
Parse, map and enable the IRQ to get event notifications from the device
tree (node "/xen").

On ARM Linux irqs are not enabled by default:

- call enable_percpu_irq for xen_events_irq (drivers are supposed
to call enable_irq after request_irq);

- reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
irq_startup, that is responsible for calling irq_unmask at startup time.
As a result event channels remain masked.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |   33 +
 arch/x86/xen/enlighten.c |1 +
 arch/x86/xen/irq.c   |1 +
 arch/x86/xen/xen-ops.h   |1 -
 drivers/xen/events.c |   18 +++---
 include/xen/events.h |2 ++
 6 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 854af1e..60d6d36 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -7,8 +7,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
 EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
+static __read_mostly int xen_events_irq = -1;
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
   unsigned long addr,
   unsigned long mfn, int nr,
@@ -65,6 +70,9 @@ int __init xen_guest_init(void)
if (of_address_to_resource(node, 0, &res))
return -EINVAL;
xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
+   xen_events_irq = irq_of_parse_and_map(node, 0);
+   pr_info("Xen support found, events_irq=%d gnttab_frame_pfn=%lx\n",
+   xen_events_irq, xen_hvm_resume_frames);
xen_domain_type = XEN_HVM_DOMAIN;
 
xen_setup_features();
@@ -114,3 +122,28 @@ int __init xen_guest_init(void)
 }
 EXPORT_SYMBOL_GPL(xen_guest_init);
 core_initcall(xen_guest_init);
+
+static irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+   xen_hvm_evtchn_do_upcall();
+   return 0;
+}
+
+static int __init xen_init_events(void)
+{
+   if (!xen_domain() || xen_events_irq < 0)
+   return -ENODEV;
+
+   xen_init_IRQ();
+
+   if (request_percpu_irq(xen_events_irq, xen_arm_callback,
+   "events", xen_vcpu)) {
+   pr_err("Error requesting IRQ %d\n", xen_events_irq);
+   return -EINVAL;
+   }
+
+   enable_percpu_irq(xen_events_irq, 0);
+
+   return 0;
+}
+postcore_initcall(xen_init_events);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 6131d43..5a30502 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..01a4dc0 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 202d4c1..2368295 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,7 +35,6 @@ void xen_set_pat(u64);
 
 char * __init xen_memory_setup(void);
 void __init xen_arch_setup(void);
-void __init xen_init_IRQ(void);
 void xen_enable_sysenter(void);
 void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 7da65d3..9b506b2 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,14 +31,16 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
+#endif
+#include 
 #include 
 #include 
 
@@ -50,6 +52,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 /*
  * This lock protects updates to the following mapping and reference-count
@@ -834,6 +839,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
struct irq_info *info = info_for_irq(irq);
WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
}
+   irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
 
 out:
mutex_unlock(&irq_mapping_update_lock);
@@ -1377,7 +1383,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 {
struct pt_regs *old_regs = set_irq_regs(regs);
 
+#ifdef CONFIG_X86
exit_idle();
+#endif
irq_enter();
 
__xen_evtchn_do_upcall();
@@ -1786,9 +1794,9 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
-void __init xen_init_IRQ(void)
+void xen_init_IRQ(void)
 {
-   int i, rc;
+   int i;
 
evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
GFP_KERNEL);
@@ -1804,6 +1812,7 @@ void __init xen_

[PATCH 12/24] xen/arm: Introduce xen_guest_init

[Stefano Stabellini]

We used to rely on a core_initcall to initialize Xen on ARM, however
core_initcalls are actually called after early consoles are initialized.
That means that hvc_xen.c is going to be initialized before Xen.

Given the lack of a better alternative, just call a new Xen
initialization function (xen_guest_init) from xen_cons_init.

xen_guest_init has to be arch independent, so write both an ARM and an
x86 implementation. The x86 implementation is currently empty because we
can be sure that xen_hvm_guest_init is called early enough.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c  |7 ++-
 arch/x86/xen/enlighten.c  |8 
 drivers/tty/hvc/hvc_xen.c |7 ++-
 include/xen/xen.h |2 ++
 4 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 8c923af..dc68074 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -44,7 +44,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
  * - one interrupt for Xen event notifications;
  * - one memory region to map the grant_table.
  */
-static int __init xen_guest_init(void)
+int __init xen_guest_init(void)
 {
int cpu;
struct xen_add_to_physmap xatp;
@@ -58,6 +58,10 @@ static int __init xen_guest_init(void)
}
xen_domain_type = XEN_HVM_DOMAIN;
 
+   /* already setup */
+   if (shared_info_page != 0 && HYPERVISOR_shared_info == shared_info_page)
+   return 0;
+
if (!shared_info_page)
shared_info_page = (struct shared_info *)
get_zeroed_page(GFP_KERNEL);
@@ -88,4 +92,5 @@ static int __init xen_guest_init(void)
}
return 0;
 }
+EXPORT_SYMBOL_GPL(xen_guest_init);
 core_initcall(xen_guest_init);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ff962d4..6131d43 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1567,4 +1567,12 @@ const struct hypervisor_x86 x86_hyper_xen_hvm __refconst 
= {
.init_platform  = xen_hvm_guest_init,
 };
 EXPORT_SYMBOL(x86_hyper_xen_hvm);
+
+int __init xen_guest_init(void)
+{
+   /* do nothing: rely on x86_hyper_xen_hvm for the initialization */
+   return 0;
+   
+}
+EXPORT_SYMBOL_GPL(xen_guest_init);
 #endif
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index dc07f56..3c04fb8 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -577,6 +577,12 @@ static void __exit xen_hvc_fini(void)
 static int xen_cons_init(void)
 {
const struct hv_ops *ops;
+   int r;
+
+   /* retrieve xen infos  */
+   r = xen_guest_init();
+   if (r < 0)
+   return r;
 
if (!xen_domain())
return 0;
@@ -584,7 +590,6 @@ static int xen_cons_init(void)
if (xen_initial_domain())
ops = &dom0_hvc_ops;
else {
-   int r;
ops = &domU_hvc_ops;
 
if (xen_hvm_domain())
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 2c0d3a5..792a4d2 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -9,8 +9,10 @@ enum xen_domain_type {
 
 #ifdef CONFIG_XEN
 extern enum xen_domain_type xen_domain_type;
+int xen_guest_init(void);
 #else
 #define xen_domain_typeXEN_NATIVE
+static inline int xen_guest_init(void) { return 0; }
 #endif
 
 #define xen_domain()   (xen_domain_type != XEN_NATIVE)
-- 
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 1/1] kthread: disable preemption during complete()

[Oleg Nesterov]

On 07/26, Thomas Gleixner wrote:
>
> On Thu, 26 Jul 2012, Peter Zijlstra wrote:
> > On Wed, 2012-07-25 at 15:40 -0700, Tejun Heo wrote:
> > > > This patch disables preemption during complete(), since we call
> > > > schedule() directly afterwards, so it will correctly enter
> > > > TASK_UNINTERRUPTIBLE. This speeds up kthread creation/binding during
> > > > cpu hotplug significantly.
> >
> > tglx has patches that make the kthread create/destroy stuff from hotplug
> > go away.. that seems like the better approach.
>
> Right. That cpu hotplug setup/teardown stuff is ugly.

Could you cc me if you send these patches?

> > The comment doesn't really make that clear.
>
> Right, the comment is crap. It has nothing to do with kthread_bind()
> and stuff. The whole purpose is to avoid the pointless preemption
> after wakeup.

Yes, but this "avoid the preemption after wakeup" can actually help
kthread_bind()->wait_task_inactive() ?

This reminds me, Peter had a patch which teaches wait_task_inactive()
to use sched_in/sched_out notifiers to avoid the polling...

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/24] xen/arm: initialize grant_table on ARM

[Stefano Stabellini]

Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c  |   13 +
 drivers/xen/grant-table.c |2 +-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 2e013cf..854af1e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,8 +1,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -51,12 +55,16 @@ int __init xen_guest_init(void)
struct xen_add_to_physmap xatp;
static struct shared_info *shared_info_page = 0;
struct device_node *node;
+   struct resource res;
 
node = of_find_compatible_node(NULL, NULL, "arm,xen");
if (!node) {
pr_info("No Xen support\n");
return 0;
}
+   if (of_address_to_resource(node, 0, &res))
+   return -EINVAL;
+   xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
xen_domain_type = XEN_HVM_DOMAIN;
 
xen_setup_features();
@@ -97,6 +105,11 @@ int __init xen_guest_init(void)
per_cpu(xen_vcpu, cpu) =
&HYPERVISOR_shared_info->vcpu_info[cpu];
}
+
+   gnttab_init();
+   if (!xen_initial_domain())
+   xenbus_probe(NULL);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(xen_guest_init);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 1d0d95e..fd2137a 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -62,7 +62,7 @@
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
-static unsigned int boot_max_nr_grant_frames;
+static unsigned int boot_max_nr_grant_frames = 1;
 static int gnttab_free_count;
 static grant_ref_t gnttab_free_head;
 static DEFINE_SPINLOCK(gnttab_list_lock);
-- 
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 11/24] xen/arm: introduce CONFIG_XEN on ARM

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 arch/arm/Kconfig |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a91009c..9c54cb4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2228,6 +2228,16 @@ config NEON
  Say Y to include support code for NEON, the ARMv7 Advanced SIMD
  Extension.
 
+config XEN_DOM0
+   def_bool y
+
+config XEN
+   bool "Xen guest support on ARM"
+   depends on ARM && OF
+   select XEN_DOM0
+   help
+ Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+
 endmenu
 
 menu "Userspace binary formats"
-- 
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 24/24] [HACK] xen/arm: implement xen_remap_domain_mfn_range

[Stefano Stabellini]

From: Ian Campbell 

Do not apply!

This is a simple, hacky implementation of xen_remap_domain_mfn_range,
using XENMAPSPACE_gmfn_foreign.

It should use same interface as hybrid x86.

Signed-off-by: Ian Campbell 
Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c   |   79 +++-
 drivers/xen/privcmd.c  |   16 +
 drivers/xen/xenfs/super.c  |7 
 include/xen/interface/memory.h |   10 --
 4 files changed, 101 insertions(+), 11 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 1476b0b..7092015 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -16,6 +16,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#include 
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
@@ -38,12 +42,85 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
 static __read_mostly int xen_events_irq = -1;
 
+#define FOREIGN_MAP_BUFFER 0x9000UL
+#define FOREIGN_MAP_BUFFER_SIZE 0x1000UL
+struct resource foreign_map_resource = {
+   .start = FOREIGN_MAP_BUFFER,
+   .end = FOREIGN_MAP_BUFFER + FOREIGN_MAP_BUFFER_SIZE,
+   .name = "Xen foreign map buffer",
+   .flags = 0,
+};
+
+static unsigned long foreign_map_buffer_pfn = FOREIGN_MAP_BUFFER >> PAGE_SHIFT;
+
+struct remap_data {
+   struct mm_struct *mm;
+   unsigned long mfn;
+   pgprot_t prot;
+};
+
+static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
+unsigned long addr, void *data)
+{
+   struct remap_data *rmd = data;
+   pte_t pte = pfn_pte(rmd->mfn, rmd->prot);
+
+   if (rmd->mfn < 0x90010)
+   pr_crit("%s: ptep %p addr %#lx => %#x / %#lx\n",
+  __func__, ptep, addr, pte_val(pte), rmd->mfn);
+
+   set_pte_at(rmd->mm, addr, ptep, pte);
+
+   rmd->mfn++;
+   return 0;
+}
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
   unsigned long addr,
   unsigned long mfn, int nr,
   pgprot_t prot, unsigned domid)
 {
-   return -ENOSYS;
+   int i, rc = 0;
+   struct remap_data rmd = {
+   .mm = vma->vm_mm,
+   .prot = prot,
+   };
+   struct xen_add_to_physmap xatp = {
+   .domid = DOMID_SELF,
+   .space = XENMAPSPACE_gmfn_foreign,
+
+   .foreign_domid = domid,
+   };
+
+   if (foreign_map_buffer_pfn + nr > ((FOREIGN_MAP_BUFFER +
+   FOREIGN_MAP_BUFFER_SIZE)>>PAGE_SHIFT)) {
+   pr_crit("RAM out of foreign map buffers...\n");
+   return -EBUSY;
+   }
+
+   for (i = 0; i < nr; i++) {
+   xatp.idx = mfn + i;
+   xatp.gpfn = foreign_map_buffer_pfn + i;
+   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+   if (rc != 0) {
+   pr_crit("foreign map add_to_physmap failed, err=%d\n", 
rc);
+   goto out;
+   }
+   }
+
+   rmd.mfn = foreign_map_buffer_pfn;
+   rc = apply_to_page_range(vma->vm_mm,
+addr,
+(unsigned long)nr << PAGE_SHIFT,
+remap_area_mfn_pte_fn, &rmd);
+   if (rc != 0) {
+   pr_crit("apply_to_page_range failed rc=%d\n", rc);
+   goto out;
+   }
+
+   foreign_map_buffer_pfn += nr;
+out:
+   return rc;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 85226cb..3e15c22 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -196,9 +198,6 @@ static long privcmd_ioctl_mmap(void __user *udata)
LIST_HEAD(pagelist);
struct mmap_mfn_state state;
 
-   if (!xen_initial_domain())
-   return -EPERM;
-
if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
return -EFAULT;
 
@@ -286,9 +285,6 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
LIST_HEAD(pagelist);
struct mmap_batch_state state;
 
-   if (!xen_initial_domain())
-   return -EPERM;
-
if (copy_from_user(&m, udata, sizeof(m)))
return -EFAULT;
 
@@ -365,6 +361,11 @@ static long privcmd_ioctl(struct file *file,
return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+   /* TODO: unmap VMA */
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -375,7 +376,8 @@ static int privcmd_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
-   

[PATCH 16/24] xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree

[Stefano Stabellini]

Only until we get the balloon driver to work.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 60d6d36..1476b0b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -121,6 +121,24 @@ int __init xen_guest_init(void)
return 0;
 }
 EXPORT_SYMBOL_GPL(xen_guest_init);
+
+/* XXX: only until balloon is properly working */
+int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
+{
+   *pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
+   get_order(nr_pages));
+   if (*pages == NULL)
+   return -ENOMEM;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
+
+void free_xenballooned_pages(int nr_pages, struct page **pages)
+{
+   kfree(*pages);
+   *pages = NULL;
+}
+EXPORT_SYMBOL_GPL(free_xenballooned_pages);
 core_initcall(xen_guest_init);
 
 static irqreturn_t xen_arm_callback(int irq, void *arg)
-- 
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 19/24] xen/arm: compile netback

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/hypercall.h |   19 +++
 drivers/net/xen-netback/netback.c|1 +
 drivers/net/xen-netfront.c   |1 +
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index 4ac0624..8a82325 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -47,4 +47,23 @@ unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 
+static inline void
+MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
+   unsigned int new_val, unsigned long flags)
+{
+   BUG();
+}
+
+static inline void
+MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
+int count, int *success_count, domid_t domid)
+{
+   BUG();
+}
+
+static inline int
+HYPERVISOR_multicall(void *call_list, int nr_calls)
+{
+   BUG();
+}
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index f4a6fca..ab4f81c 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -40,6 +40,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3089990..bf4ba2b 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
-- 
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 13/24] xen/arm: get privilege status

[Stefano Stabellini]

Use Xen features to figure out if we are privileged.

XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |7 +++
 include/xen/interface/features.h |3 +++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index dc68074..2e013cf 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,6 +59,12 @@ int __init xen_guest_init(void)
}
xen_domain_type = XEN_HVM_DOMAIN;
 
+   xen_setup_features();
+   if (xen_feature(XENFEAT_dom0))
+   xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
+   else
+   xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+
/* already setup */
if (shared_info_page != 0 && HYPERVISOR_shared_info == shared_info_page)
return 0;
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index b6ca39a..131a6cc 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -50,6 +50,9 @@
 /* x86: pirq can be used by HVM guests */
 #define XENFEAT_hvm_pirqs   10
 
+/* operation as Dom0 is supported */
+#define XENFEAT_dom0  11
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
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 18/24] xen/arm: compile blkfront and blkback

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 drivers/block/xen-blkback/blkback.c  |1 +
 include/xen/interface/io/protocols.h |3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c 
b/drivers/block/xen-blkback/blkback.c
index 73f196c..63dd5b9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -42,6 +42,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "common.h"
diff --git a/include/xen/interface/io/protocols.h 
b/include/xen/interface/io/protocols.h
index 01fc8ae..0eafaf2 100644
--- a/include/xen/interface/io/protocols.h
+++ b/include/xen/interface/io/protocols.h
@@ -5,6 +5,7 @@
 #define XEN_IO_PROTO_ABI_X86_64 "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64   "ia64-abi"
 #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
+#define XEN_IO_PROTO_ABI_ARM"arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -14,6 +15,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
 #elif defined(__powerpc64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
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 17/24] xen: allow privcmd for HVM guests

[Stefano Stabellini]

In order for privcmd mmap to work correctly, xen_remap_domain_mfn_range
needs to be implemented for HVM guests.
If it is not, mmap is going to fail later on.

Signed-off-by: Stefano Stabellini 
---
 drivers/xen/privcmd.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..85226cb 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -380,10 +380,6 @@ static struct vm_operations_struct privcmd_vm_ops = {
 
 static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 {
-   /* Unsupported for auto-translate guests. */
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return -ENOSYS;
-
/* DONTCOPY is essential for Xen because copy_page_range doesn't know
 * how to recreate these mappings */
vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
-- 
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 22/24] ARM: enable earlyprintk=xen

[Stefano Stabellini]

From: Ian Campbell 

Currently ARM setup_early_printk does not support alternative early
consoles and it always registers early_console only.

This patch adds support for xenboot_console.

Signed-off-by: Ian Campbell 
Signed-off-by: Stefano Stabellini 
---
 arch/arm/kernel/early_printk.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/early_printk.c b/arch/arm/kernel/early_printk.c
index 85aa2b2..eecfa21 100644
--- a/arch/arm/kernel/early_printk.c
+++ b/arch/arm/kernel/early_printk.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 extern void printch(int);
 
@@ -50,7 +52,14 @@ asmlinkage void early_printk(const char *fmt, ...)
 
 static int __init setup_early_printk(char *buf)
 {
-   register_console(&early_console);
+   if (!buf || !strncmp(buf, "serial", 6))
+   register_console(&early_console);
+
+#ifdef CONFIG_HVC_XEN
+   if (!strncmp(buf, "xen", 3))
+   register_console(&xenboot_console);
+#endif
+
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 21/24] arm/v2m: initialize arch_timers even if v2m_timer is not present

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 arch/arm/mach-vexpress/v2m.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index fde26ad..dee1451 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -637,16 +637,17 @@ static void __init v2m_dt_timer_init(void)
node = of_find_compatible_node(NULL, NULL, "arm,sp810");
v2m_sysctl_init(of_iomap(node, 0));
 
-   err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
-   if (WARN_ON(err))
-   return;
-   node = of_find_node_by_path(path);
-   v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
if (arch_timer_of_register() != 0)
twd_local_timer_of_register();
 
if (arch_timer_sched_clock_init() != 0)
versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 
2400);
+
+   err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
+   if (WARN_ON(err))
+   return;
+   node = of_find_node_by_path(path);
+   v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
 }
 
 static struct sys_timer v2m_dt_timer = {
-- 
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 20/24] xen: update xen_add_to_physmap interface

[Stefano Stabellini]

Update struct xen_add_to_physmap to be in sync with Xen's version of the
structure.
The size field was introduced by:

changeset:   24164:707d27fe03e7
user:Jean Guyader 
date:Fri Nov 18 13:42:08 2011 +
summary: mm: New XENMEM space, XENMAPSPACE_gmfn_range

According to the comment:

"This new field .size is located in the 16 bits padding between .domid
and .space in struct xen_add_to_physmap to stay compatible with older
versions."

This is not true on ARM where there is not padding, but it is valid on
X86, so introducing size is safe on X86 and it is going to fix the
interace for ARM.

Signed-off-by: Stefano Stabellini 
---
 include/xen/interface/memory.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index abbbff0..d8e33a9 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -163,6 +163,9 @@ struct xen_add_to_physmap {
 /* Which domain to change the mapping for. */
 domid_t domid;
 
+/* Number of pages to go through for gmfn_range */
+uint16_tsize;
+
 /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-- 
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 PATCH 13/13] driver core: firmware loader: cache devices firmware during suspend/resume cycle

[Ming Lei]

On Thu, Jul 26, 2012 at 8:43 PM, Borislav Petkov  wrote:
>> +#else
>> +static int fw_pm_notify(struct notifier_block *notify_block,
>> + unsigned long mode, void *unused)
>> +{}
>
> static inline int fw_pm...

Will add inline in -v1.


Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: bcma_bus_scan/bcma_bus_scan_early: missing iounmap

[Hauke Mehrtens]

On 07/25/2012 01:05 PM, Fengguang Wu wrote:
> Hi Hauke,
> 
> The coccinelle static checker emits these warnings:
> 
> drivers/bcma/scan.c:466:3-9: ERROR: missing iounmap; ioremap on line 451 and 
> execution via conditional on line 465
> drivers/bcma/scan.c:540:3-9: ERROR: missing iounmap; ioremap on line 515 and 
> execution via conditional on line 539
> 
> It seems we need to change the return statements to goto/break statements.
> 
> Thanks,
> Fengguang

Hi Fengguang,

Thanks for the hint on this problem, I just sent a patch to fix this to
John Linville and the linux-wireless mailing list.

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

Re: [RFC PATCH 12/13] driver core: firmware loader: use small timeout for cache device firmware

[Ming Lei]

On Thu, Jul 26, 2012 at 8:36 PM, Borislav Petkov  wrote:
> On Wed, Jul 25, 2012 at 01:00:12AM +0800, Ming Lei wrote:
>> Because device_cache_firmwares only cache the firmware which has been
>> loaded sucessfully at leat once, using a small loading timeout should
>
> least
>
>> be OK.
>
> Your commit message doesn't explain why exactly we decrease the timeout:

I have explained it. Because the firmware has been loaded successfully at least
once, so it is very probably to not timeout.

> you should probably say that this patch overrides the default 60s
> timeout because we're in pre-suspend/-hibernate mode where we have
> userspace and are able to load the firmware quickly.

No, it is not what I was saying.

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: drm/nouveau: crash regression in 3.5

[Marcin Slusarz]

On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote:
> On 25.07.2012 20:42, Marcin Slusarz wrote:
> > Good, below patch should fix this panic.
> >
> > Note that you can hit an oops in drm_handle_vblank because patch from
> > http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
> > has not been applied (yet?).
> 
> After applying your patch, it still crashes, although with a slightly 
> different stack trace. I then also applied the second patch, but that 
> doesn't make any difference. New log attached.
> 
> Looks like interrupt occurs before nouveau_software_context_new() is 
> called? Shouldn't the initialization be done from 
> nouveau_irq_preinstall() so it is available when the irq occurs? Again, 
> I am not an expert here. Just guessing...

I didn't look at it yet, but can you catch panic with maxcpus=1?

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

Re: [RFC PATCH 08/13] driver core: firmware loader: fix device lifetime

[Ming Lei]

On Thu, Jul 26, 2012 at 8:20 PM, Borislav Petkov  wrote:
>
> Ok, here's what I got from looking at the patch:
>
> Your commit message says: "Also request_firmware_nowait should be called
> in atomic context now, so fix the obsolete comments."
>
> Atomic context in my book means you're not allowed to sleep at all.

In fact, I mean the function can be called in atomic context now, and
I know some time ago the function will create kthread to execute
the request_firmware, and atomic context is not allowed.

So I remove the obsolete comment.

>
> But the comment says that it is possible to sleep a little. This is very
> wrongly formulated AFAICT.

The function can be run in both contexts, and I don't see any words which
says the function will sleep.

>
> But, since request_firmware_nowait receives a GFP mask as one of its
> arguments and some of its callers don't supply GFP_ATOMIC then this
> has nothing to do with atomic contexts at all. Then, you should simply
> explain in the comment why exactly callers aren't allowed to be sleeping
> for a long time. And using adjectives like "long" or "short" is very
> misleading in such explanations so please be more specific as to why the

It is the original one, and I don't think it is wrong. Also it
shouldn't be covered
by this patch.

Maybe I shouldn't have fixed the comment in this patch.


Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: yama_ptrace_access_check(): possible recursive locking detected

[Oleg Nesterov]

On 07/26, Fengguang Wu wrote:
>
> Here is a recursive lock possibility:
>
> ptrace_may_access()
> =>task_lock(task);
> yama_ptrace_access_check()
>   get_task_comm()
> =>  task_lock(task);

I think yama_ptrace_access_check() can simply use ->comm

Oleg.

--- x/security/yama/yama_lsm.c
+++ x/security/yama/yama_lsm.c
@@ -279,12 +279,9 @@ static int yama_ptrace_access_check(stru
}
 
if (rc) {
-   char name[sizeof(current->comm)];
printk_ratelimited(KERN_NOTICE
"ptrace of pid %d was attempted by: %s (pid %d)\n",
-   child->pid,
-   get_task_comm(name, current),
-   current->pid);
+   child->pid, current->comm, current->pid);
}
 
return rc;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tree for July 26 (vfio)

[Randy Dunlap]

On 07/25/2012 10:04 PM, Stephen Rothwell wrote:

> Hi all,
> 
> 
> Changes since 20120725:
> 
> 


on x86_64:

  CC [M]  drivers/vfio/pci/vfio_pci_intrs.o
drivers/vfio/pci/vfio_pci_intrs.c: In function 'virqfd_enable':
drivers/vfio/pci/vfio_pci_intrs.c:142:2: error: implicit declaration of 
function 'eventfd_fget'
drivers/vfio/pci/vfio_pci_intrs.c:142:7: warning: assignment makes pointer from 
integer without a cast
drivers/vfio/pci/vfio_pci_intrs.c:148:2: error: implicit declaration of 
function 'eventfd_ctx_fileget'
drivers/vfio/pci/vfio_pci_intrs.c:148:6: warning: assignment makes pointer from 
integer without a cast
make[4]: *** [drivers/vfio/pci/vfio_pci_intrs.o] Error 1



Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.5.0 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_FHANDLE=y
# CONFIG_TASKSTATS is not set
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_RCU_FANOUT_EXACT=y
CONFIG_RCU_FAST_NO_HZ=y
CONFIG_TREE_RCU_TRACE=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
# CONFIG_NET_NS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
CONFIG_RD_LZMA=y
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_HOTPLUG is not set
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
# CONFIG_EVENTFD is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_PCI_QUIRKS is not set
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFIL

Re: [PATCH 3.5 1/2] seccomp: Make syscall skipping and nr changes more consistent

[Andy Lutomirski]

On Tue, Jul 17, 2012 at 4:19 PM, Andy Lutomirski  wrote:
> This fixes two issues that could cause incompatibility between
> kernel versions:
>
>  - If a tracer uses SECCOMP_RET_TRACE to select a syscall number
>higher than the largest known syscall, emulate the unknown
>vsyscall by returning -ENOSYS.  (This is unlikely to make a
>noticeable difference on x86-64 due to the way the system call
>entry works.)
>
>  - On x86-64 with vsyscall=emulate, skipped vsyscalls were buggy.
>
> This updates the documentation accordingly.
>
> Signed-off-by: Andy Lutomirski 
> Cc: Will Drewry 
> ---
>  Documentation/prctl/seccomp_filter.txt |   74 --
>  arch/x86/kernel/vsyscall_64.c  |  110 
> +---
>  kernel/seccomp.c   |   13 +++-
>  3 files changed, 137 insertions(+), 60 deletions(-)

This is still necessary for vsyscall emulation to play nicely with
fancy seccomp tricks.  Can any of you (James?) send it toward Linus?

We might want to tag this for -stable as well if it survives in the
3.6 tree for a while.

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

Re: [PATCH 3.5 2/2] seccomp: Future-proof against silly tracers

[Andy Lutomirski]

On Tue, Jul 17, 2012 at 4:19 PM, Andy Lutomirski  wrote:
> Currently, if a tracer changes a syscall nr to __NR_future_enosys,
> behavior will differ between kernels that know about
> __NR_future_enosys (and return -ENOSYS) and older kernels (which
> return the value from pt_regs).  This is silly; we should just
> return -ENOSYS.
>
> This is unlikely to ever happen on x86 because the return value in
> pt_regs starts out as -ENOSYS, but a silly tracer can change that.
>
> Signed-off-by: Andy Lutomirski 
> Cc: Will Drewry 
> ---
>  arch/x86/include/asm/syscall.h |   11 +++
>  kernel/seccomp.c   |   15 +++
>  2 files changed, 26 insertions(+), 0 deletions(-)

Will, can you pick this, or some version of it, up in your
seccomp-for-ARM tree or wherever your development is?

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

[PATCH 03/24] xen/arm: page.h definitions

[Stefano Stabellini]

ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/page.h |   77 +++
 1 files changed, 77 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/page.h

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
new file mode 100644
index 000..6cfe9a1
--- /dev/null
+++ b/arch/arm/include/asm/xen/page.h
@@ -0,0 +1,77 @@
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define pfn_to_mfn(pfn)(pfn)
+#define phys_to_machine_mapping_valid  (1)
+#define mfn_to_pfn(mfn)(mfn)
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+#define pte_mfnpte_pfn
+#define mfn_ptepfn_pte
+
+/* Xen machine address */
+typedef struct xmaddr {
+   phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+   phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x)  ((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x)  ((xpaddr_t) { .paddr = (x) })
+
+static inline xmaddr_t phys_to_machine(xpaddr_t phys)
+{
+   unsigned offset = phys.paddr & ~PAGE_MASK;
+   return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+}
+
+static inline xpaddr_t machine_to_phys(xmaddr_t machine)
+{
+   unsigned offset = machine.maddr & ~PAGE_MASK;
+   return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+}
+/* VIRT <-> MACHINE conversion */
+#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
+#define virt_to_pfn(v)  (PFN_DOWN(__pa(v)))
+#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+   /* XXX: assuming it is mapped in the kernel 1:1 */
+   return virt_to_machine(vaddr);
+}
+
+/* XXX: this shouldn't be here */
+static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
+{
+   BUG();
+   return NULL;
+}
+
+static inline int m2p_add_override(unsigned long mfn, struct page *page,
+   struct gnttab_map_grant_ref *kmap_op)
+{
+   return 0;
+}
+
+static inline int m2p_remove_override(struct page *page, bool clear_pte)
+{
+   return 0;
+}
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+   BUG();
+   return false;
+}
+#endif /* _ASM_ARM_XEN_PAGE_H */
-- 
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/24] xen/arm: empty implementation of grant_table arch specific functions

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/Makefile  |2 +-
 arch/arm/xen/grant-table.c |   53 
 2 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/xen/grant-table.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index b9d6acc..4384103 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y  := enlighten.o hypercall.o
+obj-y  := enlighten.o hypercall.o grant-table.o
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
new file mode 100644
index 000..0a4ee80
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,53 @@
+/**
+ * grant_table.c
+ * ARM specific part
+ *
+ * Granting foreign access to our memory reservation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+  unsigned long max_nr_gframes,
+  void **__shared)
+{
+   return -1;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+{
+   return;
+}
+
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+  unsigned long max_nr_gframes,
+  grant_status_t **__shared)
+{
+   return -1;
+}
-- 
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/24] xen/arm: hypercalls

[Stefano Stabellini]

Use r12 to pass the hypercall number to the hypervisor.

We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.

Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".

Use the ISS to pass an hypervisor specific tag.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/hypercall.h |   50 ++
 arch/arm/xen/Makefile|2 +-
 arch/arm/xen/hypercall.S |   65 ++
 3 files changed, 116 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/hypercall.h
 create mode 100644 arch/arm/xen/hypercall.S

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
new file mode 100644
index 000..4ac0624
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -0,0 +1,50 @@
+/**
+ * hypercall.h
+ *
+ * Linux-specific hypervisor handling.
+ *
+ * Stefano Stabellini , Citrix, 2012
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _ASM_ARM_XEN_HYPERCALL_H
+#define _ASM_ARM_XEN_HYPERCALL_H
+
+#include 
+
+long privcmd_call(unsigned call, unsigned long a1,
+   unsigned long a2, unsigned long a3,
+   unsigned long a4, unsigned long a5);
+int HYPERVISOR_xen_version(int cmd, void *arg);
+int HYPERVISOR_console_io(int cmd, int count, char *str);
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
+int HYPERVISOR_sched_op(int cmd, void *arg);
+int HYPERVISOR_event_channel_op(int cmd, void *arg);
+unsigned long HYPERVISOR_hvm_op(int op, void *arg);
+int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+int HYPERVISOR_physdev_op(int cmd, void *arg);
+
+#endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 0bad594..b9d6acc 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y  := enlighten.o
+obj-y  := enlighten.o hypercall.o
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
new file mode 100644
index 000..038cc5b
--- /dev/null
+++ b/arch/arm/xen/hypercall.S
@@ -0,0 +1,65 @@
+/**
+ * hypercall.S
+ *
+ * Xen hypercall wrappers
+ *
+ * The Xen hypercall calling convention is very similar to the ARM
+ * procedure calling convention: the first paramter is passed in r0, the
+ * second in r1, the third in r2 and the third in r3. Considering that
+ * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
+ * in r4, differently from the procedure calling convention of using the
+ * stack for that case.
+ *
+ * The hypercall number is passed in r12.
+ *
+ * The return value is in r0.
+ *
+ * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
+ * hypercall tag.
+ *
+ * Stefano Stabellini , Citrix, 2012
+ */
+
+#include 
+#include 
+#include 
+
+
+/* HVC 0xEA1 */
+#ifdef CONFIG_THUMB2_KERNEL
+#define xen_hvc .word 0xf7e08ea1
+#else
+#define xen_hvc .word 0xe140ea71
+#endif
+
+/* We need to save and restore r4, because Xen clobbers it. */
+#define HYPERCALL(hypercall)   \
+ENTRY(HYPERVISOR_##hypercall)  \
+   mov r12, #__HYPERVISOR_##hypercall; \
+   xen_hvc;\
+   mov pc, lr; \
+ENDPROC(HYPERVISOR_##hypercall)
+
+ 

Re: [RFC PATCH 11/13] driver core: firmware: introduce devices_cache/uncache_firmwares

[Ming Lei]

On Thu, Jul 26, 2012 at 12:52 AM, Borislav Petkov  wrote:
> On Wed, Jul 25, 2012 at 01:00:11AM +0800, Ming Lei wrote:
>> This patches introduces the three helpers below:
>>
>>   void device_cache_firmwares(void)
>>   void device_uncache_firmwares(void)
>>   void device_uncache_firmwares_delay(unsigned long)
>
> I kinda don't like the plural of firmware: "firmwares". Can we call
> those
> device_cache_fw_images
> device_uncache_fw_images

Looks fine.

>
> or
> device_cache_fw_blobs
>
> or whatever?
>
>> so we can call device_cache_firmwares() to cache firmwares for
>> all devices which need firmwares to work, and the device driver
>> can get the firmware easily from kernel memory when system isn't
>> readly for completing their requests of loading firmwares.
>>
>> When system is ready for completing firmware loading, driver core
>> can call device_uncache_firmwares() or its delay version to free
>> the cached firmwares.
>>
>> The above helpers should be used to cache device firmwares during
>> system suspend/resume cycle in the following patches.
>>
>> Signed-off-by: Ming Lei 
>> ---
>>  drivers/base/firmware_class.c |  236 
>> +++--
>>  1 file changed, 230 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>> index c181e6d..7a96e75 100644
>> --- a/drivers/base/firmware_class.c
>> +++ b/drivers/base/firmware_class.c
>> @@ -22,6 +22,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>> +
>> +#include "base.h"
>>
>>  MODULE_AUTHOR("Manuel Estrada Sainz");
>>  MODULE_DESCRIPTION("Multi purpose firmware loading support");
>> @@ -91,6 +95,17 @@ struct firmware_cache {
>>   /* firmware_buf instance will be added into the below list */
>>   spinlock_t lock;
>>   struct list_head head;
>> +
>> + /*
>> +  * Name of firmware which has been cached successfully will be
>> +  * added into the below list so that device uncache helper can
>> +  * trace which firmware has been cached before.
>> +  */
>
> Comment above the list_head and maybe call the list_head fw_names or so?
>
>> + spinlock_t name_lock;
>> + struct list_head name_head;
>> + wait_queue_head_t  wait_queue;
>
> Stray \t
>
>> + int cnt;
>> + struct delayed_work work;
>>  };
>>
>>  struct firmware_buf {
>> @@ -107,6 +122,11 @@ struct firmware_buf {
>>   char fw_id[];
>>  };
>>
>> +struct fw_name_for_cache {
>> + struct list_head list;
>> + char name[];
>> +};
>
> Maybe fw_cache_entry?

Looks fine.

>
>> +
>>  struct firmware_priv {
>>   struct timer_list timeout;
>>   bool nowait;
>> @@ -214,12 +234,6 @@ static void fw_free_buf(struct firmware_buf *buf)
>>   kref_put(&buf->ref, __fw_free_buf);
>>  }
>>
>> -static void fw_cache_init(void)
>> -{
>> - spin_lock_init(&fw_cache.lock);
>> - INIT_LIST_HEAD(&fw_cache.head);
>> -}
>> -
>>  static struct firmware_priv *to_firmware_priv(struct device *dev)
>>  {
>>   return container_of(dev, struct firmware_priv, dev);
>> @@ -981,6 +995,216 @@ int uncache_firmware(const char *fw_name)
>>   return -EINVAL;
>>  }
>>
>> +static struct fw_name_for_cache *alloc_fw_name_cache(const char *name)
>> +{
>> + struct fw_name_for_cache *nc;
>> +
>> + nc = kzalloc(sizeof(nc) + strlen(name) + 1, GFP_KERNEL);
>> + if (!nc)
>> + goto exit;
>> +
>> + strcpy(nc->name, name);
>> +exit:
>> + return nc;
>> +}
>> +
>> +static void free_fw_name_cache(struct fw_name_for_cache *nc)
>> +{
>> + kfree(nc);
>> +}
>> +
>> +static void __async_dev_cache_firmware(void *fw_name,
>> + async_cookie_t cookie)
>
> Arg alignment.

I am wondering why checkpatch.pl doesn't add the check...

>
>> +{
>> + struct fw_name_for_cache *nc;
>> + struct firmware_cache *fwc = &fw_cache;
>> + char *curr_name;
>> + int ret;
>> +
>> + /* 'fw_name' is stored in devres, and it may be released,
>> +  * so allocate buffer to store the firmware name
>> +  */
>> + curr_name = kstrdup((const char *)fw_name, GFP_KERNEL);
>> + if (!curr_name) {
>> + ret = -ENOMEM;
>> + goto drop_ref;
>> + }
>> +
>> + strcpy(curr_name, fw_name);
>
> AFAICT kstrdup already copies the existing string, why do you need to
> strcpy it again?

Good catch.

>
>> +
>> + ret = cache_firmware(curr_name);
>> +
>> + if (!ret) {
>
> Invert check logic to save an indentation level:
>
> if (ret)
> goto free;
>
> nc = alloc...
>
> ...
>
>  free:
> kfree(curr_name);
>
>> + /*
>> +  * allocate/all the instance of alloc_fw_name_cache
>> +  * for uncaching later if cache_firmware returns
>> +  * successfully
>> +  */
>> + nc = alloc_fw_name_cache(curr_name);
>> +
>> + /*
>> +  * have to uncache firmware in ca

[PATCH 09/24] xen/arm: compile and run xenbus

[Stefano Stabellini]

bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
an error.

If Linux is running as an HVM domain and is running as Dom0, use
xenstored_local_init to initialize the xenstore page and event channel.

Signed-off-by: Stefano Stabellini 
---
 drivers/xen/xenbus/xenbus_comms.c |2 +-
 drivers/xen/xenbus/xenbus_probe.c |   27 +--
 drivers/xen/xenbus/xenbus_xs.c|1 +
 3 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c 
b/drivers/xen/xenbus/xenbus_comms.c
index 52fe7ad..c5aa55c 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -224,7 +224,7 @@ int xb_init_comms(void)
int err;
err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
0, "xenbus", &xb_waitq);
-   if (err <= 0) {
+   if (err < 0) {
printk(KERN_ERR "XENBUS request irq failed %i\n", err);
return err;
}
diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index b793723..3ae47c2 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -729,16 +729,23 @@ static int __init xenbus_init(void)
xenbus_ring_ops_init();
 
if (xen_hvm_domain()) {
-   uint64_t v = 0;
-   err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-   if (err)
-   goto out_error;
-   xen_store_evtchn = (int)v;
-   err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
-   if (err)
-   goto out_error;
-   xen_store_mfn = (unsigned long)v;
-   xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, 
PAGE_SIZE);
+   if (xen_initial_domain()) {
+   err = xenstored_local_init();
+   xen_store_interface =
+   phys_to_virt(xen_store_mfn << PAGE_SHIFT);
+   } else {
+   uint64_t v = 0;
+   err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+   if (err)
+   goto out_error;
+   xen_store_evtchn = (int)v;
+   err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
+   if (err)
+   goto out_error;
+   xen_store_mfn = (unsigned long)v;
+   xen_store_interface =
+   ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
+   }
} else {
xen_store_evtchn = xen_start_info->store_evtchn;
xen_store_mfn = xen_start_info->store_mfn;
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index d1c217b..f7feb3d 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "xenbus_comms.h"
-- 
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/24] xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 drivers/xen/Makefile |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index fc34886..0cfa6c47 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,11 +1,15 @@
-obj-y  += grant-table.o features.o events.o manage.o balloon.o
+ifneq ($(CONFIG_ARM),y)
+obj-y  += manage.o balloon.o
+obj-$(CONFIG_XEN_DOM0) += pci.o acpi.o
+obj-$(CONFIG_HOTPLUG_CPU)  += cpu_hotplug.o
+endif
+obj-y  += grant-table.o features.o events.o
 obj-y  += xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o  := $(nostackp)
 
 obj-$(CONFIG_BLOCK)+= biomerge.o
-obj-$(CONFIG_HOTPLUG_CPU)  += cpu_hotplug.o
 obj-$(CONFIG_XEN_XENCOMM)  += xencomm.o
 obj-$(CONFIG_XEN_BALLOON)  += xen-balloon.o
 obj-$(CONFIG_XEN_SELFBALLOONING)   += xen-selfballoon.o
@@ -17,7 +21,6 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)  += sys-hypervisor.o
 obj-$(CONFIG_XEN_PVHVM)+= platform-pci.o
 obj-$(CONFIG_XEN_TMEM) += tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)  += swiotlb-xen.o
-obj-$(CONFIG_XEN_DOM0) += pci.o acpi.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)   += xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)  += xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)   += xen-acpi-processor.o
-- 
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/24] xen/arm: Introduce xen_pfn_t for pfn and mfn types

[Stefano Stabellini]

All the original Xen headers have xen_pfn_t as mfn and pfn type, however
when they have been imported in Linux, xen_pfn_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_pfn_t and let each architecture define xen_pfn_t as they
see fit.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/interface.h  |2 ++
 arch/ia64/include/asm/xen/interface.h |2 +-
 arch/x86/include/asm/xen/interface.h  |2 ++
 include/xen/interface/grant_table.h   |4 ++--
 include/xen/interface/memory.h|6 +++---
 include/xen/interface/platform.h  |4 ++--
 include/xen/interface/xen.h   |6 +++---
 include/xen/privcmd.h |2 --
 8 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index 6c3ab59..76b1ebe 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -25,6 +25,7 @@
} while (0)
 
 #ifndef __ASSEMBLY__
+typedef uint64_t xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
@@ -35,6 +36,7 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
diff --git a/arch/ia64/include/asm/xen/interface.h 
b/arch/ia64/include/asm/xen/interface.h
index 09d5f7f..9efa068 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -67,6 +67,7 @@
 #define set_xen_guest_handle(hnd, val) do { (hnd).p = val; } while (0)
 
 #ifndef __ASSEMBLY__
+typedef unsigned long xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
@@ -79,7 +80,6 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 
-typedef unsigned long xen_pfn_t;
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 #define PRI_xen_pfn"lx"
 #endif
diff --git a/arch/x86/include/asm/xen/interface.h 
b/arch/x86/include/asm/xen/interface.h
index cbf0c9d..24c1b07 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -47,6 +47,7 @@
 #endif
 
 #ifndef __ASSEMBLY__
+typedef unsigned long xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
@@ -57,6 +58,7 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 #endif
 
 #ifndef HYPERVISOR_VIRT_START
diff --git a/include/xen/interface/grant_table.h 
b/include/xen/interface/grant_table.h
index a17d844..7da811b 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -338,7 +338,7 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_dump_table);
 #define GNTTABOP_transfer4
 struct gnttab_transfer {
 /* IN parameters. */
-unsigned long mfn;
+xen_pfn_t mfn;
 domid_t   domid;
 grant_ref_t   ref;
 /* OUT parameters. */
@@ -375,7 +375,7 @@ struct gnttab_copy {
struct {
union {
grant_ref_t ref;
-   unsigned long   gmfn;
+   xen_pfn_t   gmfn;
} u;
domid_t  domid;
uint16_t offset;
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eac3ce1..abbbff0 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -31,7 +31,7 @@ struct xen_memory_reservation {
  *   OUT: GMFN bases of extents that were allocated
  *   (NB. This command also updates the mach_to_phys translation table)
  */
-GUEST_HANDLE(ulong) extent_start;
+GUEST_HANDLE(xen_pfn_t) extent_start;
 
 /* Number of extents, and size/alignment of each (2^extent_order pages). */
 unsigned long  nr_extents;
@@ -130,7 +130,7 @@ struct xen_machphys_mfn_list {
  * any large discontiguities in the machine address space, 2MB gaps in
  * the machphys table will be represented by an MFN base of zero.
  */
-GUEST_HANDLE(ulong) extent_start;
+GUEST_HANDLE(xen_pfn_t) extent_start;
 
 /*
  * Number of extents written to the above array. This will be smaller
@@ -172,7 +172,7 @@ struct xen_add_to_physmap {
 unsigned long idx;
 
 /* GPFN where the source mapping page should appear. */
-unsigned long gpfn;
+xen_pfn_t gpfn;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index 486653f..0bea470 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -54,7 +54,

[PATCH 07/24] xen/arm: Xen detection and shared_info page mapping

[Stefano Stabellini]

Check for a "/xen" node in the device tree, if it is present set
xen_domain_type to XEN_HVM_DOMAIN and continue initialization.

Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |   56 ++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d27c2a6..8c923af 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
@@ -33,3 +36,56 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
return -ENOSYS;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * == Xen Device Tree format ==
+ * - /xen node;
+ * - compatible "arm,xen";
+ * - one interrupt for Xen event notifications;
+ * - one memory region to map the grant_table.
+ */
+static int __init xen_guest_init(void)
+{
+   int cpu;
+   struct xen_add_to_physmap xatp;
+   static struct shared_info *shared_info_page = 0;
+   struct device_node *node;
+
+   node = of_find_compatible_node(NULL, NULL, "arm,xen");
+   if (!node) {
+   pr_info("No Xen support\n");
+   return 0;
+   }
+   xen_domain_type = XEN_HVM_DOMAIN;
+
+   if (!shared_info_page)
+   shared_info_page = (struct shared_info *)
+   get_zeroed_page(GFP_KERNEL);
+   if (!shared_info_page) {
+   pr_err("not enough memory");
+   return -ENOMEM;
+   }
+   xatp.domid = DOMID_SELF;
+   xatp.idx = 0;
+   xatp.space = XENMAPSPACE_shared_info;
+   xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+   if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
+   BUG();
+
+   HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+
+   /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+* page, we use it in the event channel upcall and in some pvclock
+* related functions. We don't need the vcpu_info placement
+* optimizations because we don't use any pv_mmu or pv_irq op on
+* HVM.
+* When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
+* online but xen_hvm_init_shared_info is run at resume time too and
+* in that case multiple vcpus might be online. */
+   for_each_online_cpu(cpu) {
+   per_cpu(xen_vcpu, cpu) =
+   &HYPERVISOR_shared_info->vcpu_info[cpu];
+   }
+   return 0;
+}
+core_initcall(xen_guest_init);
-- 
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/24] xen: missing includes

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 drivers/tty/hvc/hvc_xen.c  |2 ++
 drivers/xen/grant-table.c  |1 +
 drivers/xen/xenbus/xenbus_probe_frontend.c |1 +
 include/xen/interface/xen.h|3 +++
 include/xen/privcmd.h  |1 +
 5 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 944eaeb..dc07f56 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..1d0d95e 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c 
b/drivers/xen/xenbus/xenbus_probe_frontend.c
index a31b54d..3159a37 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index a890804..4f29f33 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -10,7 +10,10 @@
 #define __XEN_PUBLIC_XEN_H__
 
 #include 
+#include 
+#ifdef CONFIG_X86
 #include 
+#endif
 
 /*
  * XEN "SYSTEM CALLS" (a.k.a. HYPERCALLS).
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..4d58881 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 
 typedef unsigned long xen_pfn_t;
 
-- 
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/24] arm: initial Xen support

[Stefano Stabellini]

- Basic hypervisor.h and interface.h definitions.
- Skelethon enlighten.c, set xen_start_info to an empty struct.
- Do not limit xen_initial_domain to PV guests.

The new code only compiles when CONFIG_XEN is set, that is going to be
added to arch/arm/Kconfig in a later patch.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/Makefile |1 +
 arch/arm/include/asm/hypervisor.h |6 +++
 arch/arm/include/asm/xen/hypervisor.h |   19 ++
 arch/arm/include/asm/xen/interface.h  |   64 +
 arch/arm/xen/Makefile |1 +
 arch/arm/xen/enlighten.c  |   35 ++
 include/xen/xen.h |2 +-
 7 files changed, 127 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/interface.h
 create mode 100644 arch/arm/xen/Makefile
 create mode 100644 arch/arm/xen/enlighten.c

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 0298b00..70aaa82 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -246,6 +246,7 @@ endif
 core-$(CONFIG_FPE_NWFPE)   += arch/arm/nwfpe/
 core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ)
 core-$(CONFIG_VFP) += arch/arm/vfp/
+core-$(CONFIG_XEN) += arch/arm/xen/
 
 # If we have a machine-specific directory, then include it in the build.
 core-y += arch/arm/kernel/ arch/arm/mm/ 
arch/arm/common/
diff --git a/arch/arm/include/asm/hypervisor.h 
b/arch/arm/include/asm/hypervisor.h
new file mode 100644
index 000..b90d9e5
--- /dev/null
+++ b/arch/arm/include/asm/hypervisor.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_ARM_HYPERVISOR_H
+#define _ASM_ARM_HYPERVISOR_H
+
+#include 
+
+#endif
diff --git a/arch/arm/include/asm/xen/hypervisor.h 
b/arch/arm/include/asm/xen/hypervisor.h
new file mode 100644
index 000..d7ab99a
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_ARM_XEN_HYPERVISOR_H
+#define _ASM_ARM_XEN_HYPERVISOR_H
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+/* Lazy mode for batching updates / context switch */
+enum paravirt_lazy_mode {
+   PARAVIRT_LAZY_NONE,
+   PARAVIRT_LAZY_MMU,
+   PARAVIRT_LAZY_CPU,
+};
+
+static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
+{
+   return PARAVIRT_LAZY_NONE;
+}
+
+#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
new file mode 100644
index 000..6c3ab59
--- /dev/null
+++ b/arch/arm/include/asm/xen/interface.h
@@ -0,0 +1,64 @@
+/**
+ * Guest OS interface to ARM Xen.
+ *
+ * Stefano Stabellini , Citrix, 2011
+ */
+
+#ifndef _ASM_ARM_XEN_INTERFACE_H
+#define _ASM_ARM_XEN_INTERFACE_H
+
+#include 
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+   typedef type * __guest_handle_ ## name
+
+#define DEFINE_GUEST_HANDLE_STRUCT(name) \
+   __DEFINE_GUEST_HANDLE(name, struct name)
+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
+#define GUEST_HANDLE(name)__guest_handle_ ## name
+
+#define set_xen_guest_handle(hnd, val) \
+   do {\
+   if (sizeof(hnd) == 8)   \
+   *(uint64_t *)&(hnd) = 0;\
+   (hnd) = val;\
+   } while (0)
+
+#ifndef __ASSEMBLY__
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint,  unsigned int);
+__DEFINE_GUEST_HANDLE(ulong, unsigned long);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(long);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* XXX: Move pvclock definitions some place arch independent */
+struct pvclock_vcpu_time_info {
+   u32   version;
+   u32   pad0;
+   u64   tsc_timestamp;
+   u64   system_time;
+   u32   tsc_to_system_mul;
+   s8tsc_shift;
+   u8flags;
+   u8pad[2];
+} __attribute__((__packed__)); /* 32 bytes */
+
+struct pvclock_wall_clock {
+   u32   version;
+   u32   sec;
+   u32   nsec;
+} __attribute__((__packed__));
+#endif
+
+#endif /* _ASM_ARM_XEN_INTERFACE_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
new file mode 100644
index 000..0bad594
--- /dev/null
+++ b/arch/arm/xen/Makefile
@@ -0,0 +1 @@
+obj-y  := enlighten.o
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
new file mode 100644
index 000..d27c2a6
--- /dev/null
+++ b/arch/arm/xen/enlighten.

[PATCH 04/24] xen/arm: sync_bitops

[Stefano Stabellini]

sync_bitops functions are equivalent to the SMP implementation of the
original functions, independently from CONFIG_SMP being defined.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/sync_bitops.h |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/sync_bitops.h

diff --git a/arch/arm/include/asm/sync_bitops.h 
b/arch/arm/include/asm/sync_bitops.h
new file mode 100644
index 000..d975092903
--- /dev/null
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -0,0 +1,17 @@
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include 
+#include 
+
+#define sync_set_bit(nr, p)_set_bit(nr, p)
+#define sync_clear_bit(nr, p)  _clear_bit(nr, p)
+#define sync_change_bit(nr, p) _change_bit(nr, p)
+#define sync_test_and_set_bit(nr, p)   _test_and_set_bit(nr, p)
+#define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
+#define sync_test_and_change_bit(nr, p)_test_and_change_bit(nr, p)
+#define sync_test_bit(nr, addr)test_bit(nr, addr)
+#define sync_cmpxchg   cmpxchg
+
+
+#endif
-- 
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 00/24] Introduce Xen support on ARM

[Stefano Stabellini]

Hi all,
this patch series implements Xen support for ARMv7 with virtualization
extensions.  It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.

It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen, and a simple ad-hoc tool to build guest domains
(marc.info/?l=xen-devel&m=134089788016546).

The patch marked with [HACK] shouldn't be applied and is part of the
series only because it is needed to create domUs.

I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts is the dts used for dom0
and it is passed to Linux by Xen, while vexpress-virt.dts is the dts
used for other domUs and it is appended in binary form to the guest
kernel image. I am not sure where they are supposed to live yet, so I am
just attaching them here so that people can actually try out this series
if they want to.

Comments are very welcome!


Ian Campbell (2):
  ARM: enable earlyprintk=xen
  [HACK] xen/arm: implement xen_remap_domain_mfn_range

Stefano Stabellini (22):
  arm: initial Xen support
  xen/arm: hypercalls
  xen/arm: page.h definitions
  xen/arm: sync_bitops
  xen/arm: empty implementation of grant_table arch specific functions
  xen: missing includes
  xen/arm: Xen detection and shared_info page mapping
  xen/arm: Introduce xen_pfn_t for pfn and mfn types
  xen/arm: compile and run xenbus
  xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM
  xen/arm: introduce CONFIG_XEN on ARM
  xen/arm: Introduce xen_guest_init
  xen/arm: get privilege status
  xen/arm: initialize grant_table on ARM
  xen/arm: receive Xen events on ARM
  xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
  xen: allow privcmd for HVM guests
  xen/arm: compile blkfront and blkback
  xen/arm: compile netback
  xen: update xen_add_to_physmap interface
  arm/v2m: initialize arch_timers even if v2m_timer is not present
  hvc_xen: allow dom0_write_console for HVM guests

 arch/arm/Kconfig   |   10 ++
 arch/arm/Makefile  |1 +
 arch/arm/include/asm/hypervisor.h  |6 +
 arch/arm/include/asm/sync_bitops.h |   17 ++
 arch/arm/include/asm/xen/hypercall.h   |   69 
 arch/arm/include/asm/xen/hypervisor.h  |   19 +++
 arch/arm/include/asm/xen/interface.h   |   66 
 arch/arm/include/asm/xen/page.h|   77 +
 arch/arm/kernel/early_printk.c |   11 ++-
 arch/arm/mach-vexpress/v2m.c   |   11 +-
 arch/arm/xen/Makefile  |1 +
 arch/arm/xen/enlighten.c   |  244 
 arch/arm/xen/grant-table.c |   53 ++
 arch/arm/xen/hypercall.S   |   65 
 arch/ia64/include/asm/xen/interface.h  |2 +-
 arch/x86/include/asm/xen/interface.h   |2 +
 arch/x86/xen/enlighten.c   |9 +
 arch/x86/xen/irq.c |1 +
 arch/x86/xen/xen-ops.h |1 -
 drivers/block/xen-blkback/blkback.c|1 +
 drivers/net/xen-netback/netback.c  |1 +
 drivers/net/xen-netfront.c |1 +
 drivers/tty/hvc/hvc_xen.c  |   14 +-
 drivers/xen/Makefile   |9 +-
 drivers/xen/events.c   |   18 ++-
 drivers/xen/grant-table.c  |3 +-
 drivers/xen/privcmd.c  |   20 +--
 drivers/xen/xenbus/xenbus_comms.c  |2 +-
 drivers/xen/xenbus/xenbus_probe.c  |   27 ++--
 drivers/xen/xenbus/xenbus_probe_frontend.c |1 +
 drivers/xen/xenbus/xenbus_xs.c |1 +
 drivers/xen/xenfs/super.c  |7 +
 include/xen/events.h   |2 +
 include/xen/interface/features.h   |3 +
 include/xen/interface/grant_table.h|4 +-
 include/xen/interface/io/protocols.h   |3 +
 include/xen/interface/memory.h |   19 ++-
 include/xen/interface/platform.h   |4 +-
 include/xen/interface/xen.h|9 +-
 include/xen/privcmd.h  |3 +-
 include/xen/xen.h  |4 +-
 41 files changed, 763 insertions(+), 58 deletions(-)


A branch based on 3.5-rc7 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.5-rc7-arm-1

Cheers,

Stefano/*
 * ARM Ltd. Versatile Express
 *
 * CoreTile Express A15x2 (version with Test Chip 1)
 * Cortex-A15 MPCore (V2P-CA15)
 *
 * HBI-0237A
 */

/dts-v1/;

/ {
model = "V2P-CA15";
arm,hbi = <0x237>;
compatible = "arm,vexpress,v2p-ca15,tc1", "arm,vexpress,v2p-ca15", 
"arm,vexpress";

#address-cells = <1>;
#size-cells = <1>;

interrupt-p

Re: [PATCH 1/2] regulator: whitespace

[Mark Brown]

On Thu, Jul 26, 2012 at 05:29:14PM +0200, Michael Jones wrote:

> So I suppose the changelog should have been something like:
> regulator: whitespace- indent with tabs not spaces

Yes.  I'll apply after the merge window.


signature.asc
Description: Digital signature

Re: [PATCH v2 1/1] mmc: block: Add write packing control

[S, Venkatraman]

On Tue, Jul 24, 2012 at 2:14 PM,   wrote:
> On Mon, July 23, 2012 5:22 am, S, Venkatraman wrote:
>> On Mon, Jul 23, 2012 at 5:13 PM,   wrote:
>>> On Wed, July 18, 2012 12:26 am, Chris Ball wrote:
 Hi,  [removing Jens and the documentation list, since now we're
> talking about the MMC side only]
 On Wed, Jul 18 2012, me...@codeaurora.org wrote:
> Is there anything else that holds this patch from being pushed to
>>> mmc-next?
 Yes, I'm still uncomfortable with the write packing patchsets for a
>>> couple of reasons, and I suspect that the sum of those reasons means that
>>> we should probably plan on holding off merging it until after 3.6.
 Here are the open issues; please correct any misunderstandings: With
> Seungwon's patchset ("Support packed write command"):
 * I still don't have a good set of representative benchmarks showing
   what kind of performance changes come with this patchset.  It seems
>>> like we've had a small amount of testing on one controller/eMMC part combo
>>> from Seungwon, and an entirely different test from Maya, and the
> results
>>> aren't documented fully anywhere to the level of describing what the
> hardware was, what the test was, and what the results were before and
> after the patchset.
>>> Currently, there is only one card vendor that supports packed commands.
> Following are our sequential write (LMDD) test results on 2 of our
> targets
>>> (in MB/s):
>>>No packingpacking
>>> Target 1 (SDR 50MHz) 15   25
>>> Target 2 (DDR 50MHz) 20   30
 With the reads-during-writes regression:
 * Venkat still has open questions about the nature of the read
   regression, and thinks we should understand it with blktrace before
>>> trying to fix it.  Maya has a theory about writes overwhelming reads, but
>>> Venkat doesn't understand why this would explain the observed
>>> bandwidth drop.
>>> The degradation of read due to writes is not a new behavior and exists
> also without the write packing feature (which only increases the
> degradation). Our investigation of this phenomenon led us to the
> Conclusion that a new scheduling policy should be used for mobile
> devices,
>>> but this is not related to the current discussion of the write packing
> feature.
>>> The write packing feature increases the degradation of read due to
> write
>>> since it allows the MMC to fetch many write requests in a row, instead of
>>> fetching only one at a time.  Therefore some of the read requests will
> have to wait for the completion of more write requests before they can
> be
>>> issued.
>>
>> I am a bit puzzled by this claim. One thing I checked carefully when
> reviewing write packing patches from SJeon was that the code didn't
> plough through a mixed list of reads and writes and selected only
> writes.
>> This section of the code in "mmc_blk_prep_packed_list()", from v8
> patchset..
>> 
>> +   if (rq_data_dir(cur) != rq_data_dir(next)) {
>> +   put_back = 1;
>> +   break;
>> +   }
>> 
>>
>> means that once a read is encountered in the middle of write packing,
> the packing is stopped at that point and it is executed. Then the next
> blk_fetch_request should get the next read and continue as before.
>>
>> IOW, the ordering of reads and writes is _not_ altered when using packed
> commands.
>> For example if there were 5 write requests, followed by 1 read,
>> followed by 5 more write requests in the request_queue, the first 5
> writes will be executed as one "packed command", then the read will be
> executed, and then the remaining 5 writes will be executed as one
> "packed command". So the read does not have to wait any more than it
> waited before (packing feature)
>
> Let me try to better explain with your example.
> Without packing the MMC layer will fetch 2 write requests and wait for the
> first write request completion before fetching another write request.
> During this time the read request could be inserted into the CFQ and since
> it has higher priority than the async write it will be dispatched in the
> next fetch. So, the result would be 2 write requests followed by one read
> request and the read would have to wait for completion of only 2 write
> requests.
> With packing, all the 5 write requests will be fetched in a row, and then
> the read will arrive and be dispatched in the next fetch. Then the read
> will have to wait for the completion of 5 write requests.
>
> Few more clarifications:
> Due to the plug list mechanism in the block layer the applications can
> "aggregate" several requests to be inserted into the scheduler before
> waking the MMC queue thread.
> This leads to a situation where there are several write requests in the
> CFQ queue when MMC starts to do the fetches.
>
> If the read was inserted while we are building the packed command then I
> agree that we should have seen less effect on the read performance.

Re: [PATCH 1/2] regulator: whitespace

[Michael Jones]

On 07/26/2012 05:15 PM, Mark Brown wrote:

On Thu, Jul 26, 2012 at 05:12:59PM +0200, Michael Jones wrote:

On 07/26/2012 04:44 PM, Mark Brown wrote:



Your changelog says "whitespace" and is otherwise blank...  what is the
problem you think you are fixing here?



I don't see what you're seeing.


I'm not seeing anything at all.  That's the problem.


Here:
https://lkml.org/lkml/2012/7/26/255
I see the patch which replaces non-uniform spaces with tabs.


...and only has a one word changelog.



Sorry, I misunderstood.  I thought you saw _only_ a one word change log, 
and not even the patch.  I think I answered your question above now, right?

Q: what is the problem you think you are fixing here?
A: some lines were indented with spaces, while most of them are indented 
with tabs.


So I suppose the changelog should have been something like:
regulator: whitespace- indent with tabs not spaces

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/21] ASoC: io: Prevent use of regmap if request fails

[Mark Brown]

On Thu, Jul 26, 2012 at 04:23:33PM +0100, Lee Jones wrote:

> What's my 'control data'? It's not used in the original codec patch.

> The old way wants to go:

> snd_soc_update_bits() -> snd_soc_read() -> ab8500_codec_read_reg()

> When then calls back into the abx500.

> So what 'control data' should I be storing in the codec struct?

You're supposed to use it for the data you use to call back into the
underlying I/O code.


signature.asc
Description: Digital signature

Re: [PATCH 20/21] ASoC: codecs: Enable AB8500 CODEC for Device Tree

[Mark Brown]

On Thu, Jul 26, 2012 at 04:19:33PM +0100, Lee Jones wrote:

> Okay, so your suggestion is to strip out all of the sub-devices
> under the AB8500. It's doable, but will take some restructuring and
> thinking about. This is a job for another day. I think it's okay to
> continue with the current semantics for the time-being. The line
> we're discussing does need to be split out though. I didn't mean to
> merge it in with the ASoC stuff.

Yes, well any that aren't reusable at any rate.  If you could relocate
the device into another SoC integation that'd be different.


signature.asc
Description: Digital signature

Re: [PATCH 07/21] ASoC: io: Prevent use of regmap if request fails

[Lee Jones]

On 26/07/12 16:12, Mark Brown wrote:

On Thu, Jul 26, 2012 at 03:51:13PM +0100, Lee Jones wrote:


I don't think we want to use regmap at all, but we're forced to by
soc-core. How do we over-ride that behavior? By writing some
nonsense into codec->control_data?


You should use that for your control data, yes - you're not forced to
use regmap at all.  Like I say we've got a bunch of drivers doing so
already.


What's my 'control data'? It's not used in the original codec patch.

The old way wants to go:

snd_soc_update_bits() -> snd_soc_read() -> ab8500_codec_read_reg()

When then calls back into the abx500.

So what 'control data' should I be storing in the codec struct?

--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/13] UAPI header file split

[David Howells]

Michael Kerrisk  wrote:

> I haven't looked over the changes yet, but what do my scripts now say?
> (If all's well, they generate no output beyond the list of files.)

Okay, the comparator script gives me:

warthog>sh /tmp/mtk-cmp.sh 
 include/linux/irqnr.h include/uapi/linux/irqnr.h
 * Generic irq_desc iterators:

That loss I can live with, and so can Thomas.  I suspect the comment is in the
wrong place anyway, so it can be added back after in the right place.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] Problem with commit cf03c5dac83609f09d9f0e9fa3c09d86daed614d

[Seth Forshee]

On Thu, Jul 26, 2012 at 05:07:57PM +0200, Dirk Gouders wrote:
> Hi Seth,
> 
> thanks for your reply and sorry for the noise.
> 
> I followed your advice and tried to boot with the WLAN interface turned
> off, and the problem still exists.  I'll start a new bisect session,
> probably with one of the commits you mentioned as the first good commit.

Just to make sure three's not any confusion ...

What I was suggesting was not just disabling the network interface but
completely preventing brcmsmac from being loaded. The oops you saw
happens in the context of the driver's probe function and would happen
regardless of whether or not the interface is enabled.

Seth

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] uprobes: don't enable/disable signle step if the user did it

[Sebastian Andrzej Siewior]

If someone is using single stepping over uprobe brackpoint then after
we pass the uprobe single step, single stepping is disabled and the user
who enebaled them in the first place does not know anything about this.

This patch avoids enabling / disabling the single step mode if it is
already enabled.

Signed-off-by: Sebastian Andrzej Siewior 
---
 include/linux/uprobes.h |2 ++
 kernel/events/uprobes.c |   10 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index efe4b33..1be2d44 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -44,6 +44,8 @@ struct inode;
 #define UPROBE_RUN_HANDLER 0x2
 /* Can skip singlestep */
 #define UPROBE_SKIP_SSTEP  0x4
+/* user does also singlestep */
+#define UPROBE_USER_SSTEP  0x8
 
 struct uprobe_consumer {
int (*handler)(struct uprobe_consumer *self, struct pt_regs *regs);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f935327..772eb3a 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1528,7 +1528,10 @@ static void handle_swbp(struct pt_regs *regs)
 
utask->state = UTASK_SSTEP;
if (!pre_ssout(uprobe, regs, bp_vaddr)) {
-   user_enable_single_step(current);
+   if (test_tsk_thread_flag(current, TIF_SINGLESTEP))
+   uprobe->flags |= UPROBE_USER_SSTEP;
+   else
+   user_enable_single_step(current);
return;
}
 
@@ -1569,7 +1572,10 @@ static void handle_singlestep(struct uprobe_task *utask, 
struct pt_regs *regs)
put_uprobe(uprobe);
utask->active_uprobe = NULL;
utask->state = UTASK_RUNNING;
-   user_disable_single_step(current);
+   if (uprobe->flags & UPROBE_USER_SSTEP)
+   uprobe->flags &= ~UPROBE_USER_SSTEP;
+   else
+   user_disable_single_step(current);
xol_free_insn_slot(current);
 
spin_lock_irq(¤t->sighand->siglock);
-- 
1.7.10.4

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

Re: linux-next: Tree for July 26 (uml)

[Randy Dunlap]

On 07/25/2012 10:04 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Please do not add anything to linux-next included branches/series that is
> destined for v3.7 until after v3.6-rc1 is released.
> 
> Reminder: do not rebase your branches before asking Linus to pull them ...
> 
> Changes since 20120725:
> 



uml on x86_64 (defconfig) build fails with:

  CC  arch/x86/um/../kernel/module.o
arch/x86/um/../kernel/module.c:96:5: error: redefinition of 'apply_relocate_add'
include/linux/moduleloader.h:64:19: note: previous definition of 
'apply_relocate_add' was here
make[2]: *** [arch/x86/um/../kernel/module.o] Error 1



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/21] ASoC: codecs: Enable AB8500 CODEC for Device Tree

[Lee Jones]

On 26/07/12 15:43, Mark Brown wrote:

On Thu, Jul 26, 2012 at 03:15:01PM +0100, Lee Jones wrote:

Sorry missed this:



Why are we doing this?  The MFD cells are a totally Linux specific
thing, there's no reason to represent them in the device tree unless
they're in some way reusable and the "ab8500-codec" name suggests that's
unlikely.  Just put the properties on the parent node and instantiate
the MFD cell as normal.



We have all of the AB8500 devices into the Device Tree to accurately
represent the hardware. We will also be passing configuration
information into the AB8500 Codec from Device Tree. The only reason
we're still registering them using the MFD API is to overcome
addressing issues encountered earlier. Each 'device' still belongs
in the 'device' tree.


The device here is the AB8500.  The fact that Linux chooses to represent
it as an MFD with a particular set of subdrivers is a Linux specific
decision and may well change over time.  For example it's likely that
we'll want to migrate the clocks out of the audio driver and into the
clock API when that becomes useful.  Similarly currently a lot of these
devices use ASoC level jack detection but that's going to move over to
extcon over time.

There's no way you're going to be able to reuse this for anything that
isn't an AB8500, there's no abstraction of the SoC integration here.  If
you had clearly identifiable, repeatable IPs which you could reasonably
bind to a different bit of silicon then that'd be different but there's
nothing like that here.  We already know that the functionality covered
by the driver is going to be present simply by virtue of knowing that
there's an AB8500 and similarly there's no real way this driver could
ever be used without the core driver.  All the "device" in the device
tree is doing is serving as a container to place some of the DT
properties into, this needs to be separated out from the instantiation
of the Linux device driver.  There's nothing stopping the driver from
looking at the OF node of its parent here.

The goal here isn't just to copy the Linux device model and platform
data into device tree bindings, the device tree bindings need to think
about what the chip actually is so they can be reused by other OSs and
by future versions of Linux.


If we were to take this Device Tree and use it on something
non-Linux, that OS will still need to know about each of the AB8500
devices and every associated configuration option. Only in Linux do
we continue to register them though a different API, which doesn't
affect any other OS.


Another OS might have a different idea about how it's going to split up
the chip which better fits with the models which that OS has for the
functions present on the device.  The reason this is a distinct device
in Linux is all to do with how Linux models the hardware.


Okay, so your suggestion is to strip out all of the sub-devices under 
the AB8500. It's doable, but will take some restructuring and thinking 
about. This is a job for another day. I think it's okay to continue with 
the current semantics for the time-being. The line we're discussing does 
need to be split out though. I didn't mean to merge it in with the ASoC 
stuff.


--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/urgent] x86/mce: Add quirk for instruction recovery on Sandy Bridge processors

[tip-bot for Tony Luck]

Commit-ID:  61b0fccd7f114573f973dfe25d864608822dc09e
Gitweb: http://git.kernel.org/tip/61b0fccd7f114573f973dfe25d864608822dc09e
Author: Tony Luck 
AuthorDate: Thu, 19 Jul 2012 11:28:46 -0700
Committer:  Ingo Molnar 
CommitDate: Thu, 26 Jul 2012 15:05:47 +0200

x86/mce: Add quirk for instruction recovery on Sandy Bridge processors

Sandy Bridge processors follow the SDM (Vol 3B, Table 15-20) and
set both the RIPV and EIPV bits in the MCG_STATUS register to
zero for machine checks during instruction fetch. This is more
than a little counter-intuitive and means that Linux cannot
recover from these errors. Rather than insert special case code
at several places in mce.c and mce-severity.c, we pretend the
EIPV bit was set for just this case early in processing the
machine check.

Acked-by: Borislav Petkov 
Signed-off-by: Tony Luck 
Cc: Chen Gong 
Cc: Huang Ying 
Cc: Hidetoshi Seto 
Link: 
http://lkml.kernel.org/r/180a06f3f357cf9f78259ae443a082b14a29535b.1343078495.git.tony.l...@intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/mcheck/mce.c |   43 +++--
 1 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 5a5a5dc..8cf60e2 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -105,6 +105,8 @@ DEFINE_PER_CPU(mce_banks_t, mce_poll_banks) = {
 
 static DEFINE_PER_CPU(struct work_struct, mce_work);
 
+static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs);
+
 /*
  * CPU/chipset specific EDAC code can register a notifier call here to print
  * MCE errors in a human-readable form.
@@ -652,14 +654,18 @@ EXPORT_SYMBOL_GPL(machine_check_poll);
  * Do a quick check if any of the events requires a panic.
  * This decides if we keep the events around or clear them.
  */
-static int mce_no_way_out(struct mce *m, char **msg, unsigned long *validp)
+static int mce_no_way_out(struct mce *m, char **msg, unsigned long *validp,
+ struct pt_regs *regs)
 {
int i, ret = 0;
 
for (i = 0; i < banks; i++) {
m->status = mce_rdmsrl(MSR_IA32_MCx_STATUS(i));
-   if (m->status & MCI_STATUS_VAL)
+   if (m->status & MCI_STATUS_VAL) {
__set_bit(i, validp);
+   if (quirk_no_way_out)
+   quirk_no_way_out(i, m, regs);
+   }
if (mce_severity(m, tolerant, msg) >= MCE_PANIC_SEVERITY)
ret = 1;
}
@@ -1042,7 +1048,7 @@ void do_machine_check(struct pt_regs *regs, long 
error_code)
*final = m;
 
memset(valid_banks, 0, sizeof(valid_banks));
-   no_way_out = mce_no_way_out(&m, &msg, valid_banks);
+   no_way_out = mce_no_way_out(&m, &msg, valid_banks, regs);
 
barrier();
 
@@ -1418,6 +1424,34 @@ static void __mcheck_cpu_init_generic(void)
}
 }
 
+/*
+ * During IFU recovery Sandy Bridge -EP4S processors set the RIPV and
+ * EIPV bits in MCG_STATUS to zero on the affected logical processor (SDM
+ * Vol 3B Table 15-20). But this confuses both the code that determines
+ * whether the machine check occurred in kernel or user mode, and also
+ * the severity assessment code. Pretend that EIPV was set, and take the
+ * ip/cs values from the pt_regs that mce_gather_info() ignored earlier.
+ */
+static void quirk_sandybridge_ifu(int bank, struct mce *m, struct pt_regs 
*regs)
+{
+   if (bank != 0)
+   return;
+   if ((m->mcgstatus & (MCG_STATUS_EIPV|MCG_STATUS_RIPV)) != 0)
+   return;
+   if ((m->status & (MCI_STATUS_OVER|MCI_STATUS_UC|
+ MCI_STATUS_EN|MCI_STATUS_MISCV|MCI_STATUS_ADDRV|
+ MCI_STATUS_PCC|MCI_STATUS_S|MCI_STATUS_AR|
+ MCACOD)) !=
+(MCI_STATUS_UC|MCI_STATUS_EN|
+ MCI_STATUS_MISCV|MCI_STATUS_ADDRV|MCI_STATUS_S|
+ MCI_STATUS_AR|MCACOD_INSTR))
+   return;
+
+   m->mcgstatus |= MCG_STATUS_EIPV;
+   m->ip = regs->ip;
+   m->cs = regs->cs;
+}
+
 /* Add per CPU specific workarounds here */
 static int __cpuinit __mcheck_cpu_apply_quirks(struct cpuinfo_x86 *c)
 {
@@ -1515,6 +1549,9 @@ static int __cpuinit __mcheck_cpu_apply_quirks(struct 
cpuinfo_x86 *c)
 */
if (c->x86 == 6 && c->x86_model <= 13 && mce_bootlog < 0)
mce_bootlog = 0;
+
+   if (c->x86 == 6 && c->x86_model == 45)
+   quirk_no_way_out = quirk_sandybridge_ifu;
}
if (monarch_timeout < 0)
monarch_timeout = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkm

[tip:x86/urgent] x86/mce: Move MCACOD defines from mce-severity. c to

[tip-bot for Tony Luck]

Commit-ID:  736edce5f395b8309a61aa62c36c4356abc83219
Gitweb: http://git.kernel.org/tip/736edce5f395b8309a61aa62c36c4356abc83219
Author: Tony Luck 
AuthorDate: Thu, 19 Jul 2012 11:21:53 -0700
Committer:  Ingo Molnar 
CommitDate: Thu, 26 Jul 2012 15:05:47 +0200

x86/mce: Move MCACOD defines from mce-severity.c to 

We will need some of these values in mce.c. Move them to the
appropriate header file so they are available.

Acked-by: Borislav Petkov 
Signed-off-by: Tony Luck 
Cc: Chen Gong 
Cc: Huang Ying 
Cc: Hidetoshi Seto 
Link: 
http://lkml.kernel.org/r/0ccfb1af5fe35e537b7cd8e4d448bf7d851dbfb9.1343078495.git.tony.l...@intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/mce.h|8 
 arch/x86/kernel/cpu/mcheck/mce-severity.c |7 ---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 441520e..a3ac52b 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -33,6 +33,14 @@
 #define MCI_STATUS_PCC   (1ULL<<57)  /* processor context corrupt */
 #define MCI_STATUS_S(1ULL<<56)  /* Signaled machine check */
 #define MCI_STATUS_AR   (1ULL<<55)  /* Action required */
+#define MCACOD   0x /* MCA Error Code */
+
+/* Architecturally defined codes from SDM Vol. 3B Chapter 15 */
+#define MCACOD_SCRUB   0x00C0  /* 0xC0-0xCF Memory Scrubbing */
+#define MCACOD_SCRUBMSK0xfff0
+#define MCACOD_L3WB0x017A  /* L3 Explicit Writeback */
+#define MCACOD_DATA0x0134  /* Data Load */
+#define MCACOD_INSTR   0x0150  /* Instruction Fetch */
 
 /* MCi_MISC register defines */
 #define MCI_MISC_ADDR_LSB(m)   ((m) & 0x3f)
diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c 
b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index 413c2ce..1301762 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -55,13 +55,6 @@ static struct severity {
 #define MCI_UC_S (MCI_STATUS_UC|MCI_STATUS_S)
 #define MCI_UC_SAR (MCI_STATUS_UC|MCI_STATUS_S|MCI_STATUS_AR)
 #defineMCI_ADDR (MCI_STATUS_ADDRV|MCI_STATUS_MISCV)
-#define MCACOD 0x
-/* Architecturally defined codes from SDM Vol. 3B Chapter 15 */
-#define MCACOD_SCRUB   0x00C0  /* 0xC0-0xCF Memory Scrubbing */
-#define MCACOD_SCRUBMSK0xfff0
-#define MCACOD_L3WB0x017A  /* L3 Explicit Writeback */
-#define MCACOD_DATA0x0134  /* Data Load */
-#define MCACOD_INSTR   0x0150  /* Instruction Fetch */
 
MCESEV(
NO, "Invalid",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf/x86: Fix missing struct before structure name

[tip-bot for Jovi Zhang]

Commit-ID:  35d56ca9d401d9d0ac8d91e4db1485af5f38f6fd
Gitweb: http://git.kernel.org/tip/35d56ca9d401d9d0ac8d91e4db1485af5f38f6fd
Author: Jovi Zhang 
AuthorDate: Tue, 17 Jul 2012 10:14:41 +0800
Committer:  Ingo Molnar 
CommitDate: Thu, 26 Jul 2012 15:04:34 +0200

perf/x86: Fix missing struct before structure name

When CONFIG_PERF_EVENTS disabled, there will have a compiliation
error, because missing struct before structure name.

Signed-off-by: Jovi Zhang 
Cc: Peter Zijlstra 
Cc: Jiri Kosina 
Link: 
http://lkml.kernel.org/r/cacv3sbkf%3dcx%2b2jwewesfca6rboq3wdm4-5ac9mubtvbctmr...@mail.gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/perf_event.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/perf_event.h 
b/arch/x86/include/asm/perf_event.h
index c78f14a..dab3935 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -234,7 +234,7 @@ extern struct perf_guest_switch_msr 
*perf_guest_get_msrs(int *nr);
 extern void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap);
 extern void perf_check_microcode(void);
 #else
-static inline perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
+static inline struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
 {
*nr = 0;
return NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/21] ASoC: codecs: Enable AB8500 CODEC for Device Tree

[Lee Jones]

On 26/07/12 16:14, Mark Brown wrote:

On Thu, Jul 26, 2012 at 04:01:14PM +0100, Lee Jones wrote:


This is the only value which the user can pick an obscure value,
such as 913, thinking they can pick 913mV. I'm happy to fall-back,
as long as Ola is too.


Erroring out if they pick an invalid value is fine, I'm more concerned
with the case where no property is supplied at all.


Hmmm... I'll have a think.

--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/