Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Michael Kerrisk (man-pages)
On 01/09/2015 07:02 PM, David Drysdale wrote:
> On Fri, Jan 9, 2015 at 3:47 PM, Michael Kerrisk (man-pages)
>  wrote:
>> On 11/24/2014 12:53 PM, David Drysdale wrote:
>>> Signed-off-by: David Drysdale 
>>> ---
>>>  man2/execveat.2 | 153 
>>> 
>>>  1 file changed, 153 insertions(+)
>>>  create mode 100644 man2/execveat.2
>>
>> David,
>>
>> Thanks for the very nicely prepared man page. I've done
>> a few very light edits, and will release the version below
>> with the next man-pages release.
> 
> Many thanks, one error (of mine) in 2 places pointed out below.

Well, the first error was yours. The second error was mine,
when I replicated your info about AT_SYMLINK_NOFOLLOW
into the ERRORS without verifying it. (Sorry about that!)

Both cases fixed now.

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Michael Kerrisk (man-pages)
On 01/09/2015 06:46 PM, David Drysdale wrote:
> On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker  wrote:
>> On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
>>> On 11/24/2014 12:53 PM, David Drysdale wrote:
 Signed-off-by: David Drysdale 
 ---
  man2/execveat.2 | 153 
 
  1 file changed, 153 insertions(+)
  create mode 100644 man2/execveat.2
>>>
>>> David,
>>>
>>> Thanks for the very nicely prepared man page. I've done
>>> a few very light edits, and will release the version below
>>> with the next man-pages release.
>>>
>>> I have one question. In the message accompanying
>>> commit 51f39a1f0cea1cacf8c787f652f26dfee9611874 you wrote:
>>>
>>>   The filename fed to the executed program as argv[0] (or the name of the
>>>   script fed to a script interpreter) will be of the form "/dev/fd/"
>>>   (for an empty filename) or "/dev/fd//", effectively
>>>   reflecting how the executable was found.  This does however mean that
>>>   execution of a script in a /proc-less environment won't work; also, script
>>>   execution via an O_CLOEXEC file descriptor fails (as the file will not be
>>>   accessible after exec).
>>>
>>> How does one produce this situation where the execed program sees
>>> argv[0] as a /dev/fd path? (i.e., what would the execveat()
>>> call look like?) I tried to produce this scenario, but could not.
>>
>> I think this is wrong. argv[0] is an arbitrary string provided by the
>> caller and would never be derived from the fd passed.
> 
> Yeah, I think I just wrote that wrong, it's only relevant for scripts.
> As Rich says, for normal binaries argv[0] is just the argv[0] that
> was passed into the execve[at] call.  For a script, the code in
> fs/binfmt_script.c will remove the original argv[0] and put the
> interpreter name and the script filename (e.g. "/bin/sh",
> "/dev/fd/6/script") in as 2 arguments in its place.

Yep, got it now.

> [As an aside, IIRC the filename does get put into the new
> process's memory, up above the environment strings -- but
> that copy isn't visible via argv nor envp.]
> 
>> It's AT_EXECFN,
>> /proc/self/exe, and filenames shown elsewhere in /proc that may be
>> derived in odd ways.
>>
>> I would also move the text about O_CLOEXEC to a BUGS or NOTES section
>> rather than the main description. The long-term intent should be that
>> script execution this way should work. IIRC this was discussed earlier
>> in the thread.
> 
> I may be misremembering, but I thought we hoped to be able to fix
> execveat of a script without /proc in future, but didn't expect to fix
> execveat of a script via an O_CLOEXEC fd (because in the latter
> case the fd gets closed before the script interpreter runs, so even
> if the interpreter (or a special filesystem) does clever things for names
> starting with "/dev/fd/..." the file descriptor is already gone).

See my other replies (and of course, Rich's). It does seem there is 
a real problem to be solved here.

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Michael Kerrisk (man-pages)
On 01/09/2015 05:13 PM, Rich Felker wrote:
> On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
>> On 11/24/2014 12:53 PM, David Drysdale wrote:
>>> Signed-off-by: David Drysdale 
>>> ---
>>>  man2/execveat.2 | 153 
>>> 
>>>  1 file changed, 153 insertions(+)
>>>  create mode 100644 man2/execveat.2
>>
>> David,
>>
>> Thanks for the very nicely prepared man page. I've done 
>> a few very light edits, and will release the version below 
>> with the next man-pages release.
>>
>> I have one question. In the message accompanying
>> commit 51f39a1f0cea1cacf8c787f652f26dfee9611874 you wrote:
>>
>>   The filename fed to the executed program as argv[0] (or the name of the
>>   script fed to a script interpreter) will be of the form "/dev/fd/"
>>   (for an empty filename) or "/dev/fd//", effectively
>>   reflecting how the executable was found.  This does however mean that
>>   execution of a script in a /proc-less environment won't work; also, script
>>   execution via an O_CLOEXEC file descriptor fails (as the file will not be
>>   accessible after exec).
>>
>> How does one produce this situation where the execed program sees 
>> argv[0] as a /dev/fd path? (i.e., what would the execveat()
>> call look like?) I tried to produce this scenario, but could not.
> 
> I think this is wrong. argv[0] is an arbitrary string provided by the
> caller and would never be derived from the fd passed. It's AT_EXECFN,
> /proc/self/exe, and filenames shown elsewhere in /proc that may be
> derived in odd ways.
> 
> I would also move the text about O_CLOEXEC to a BUGS or NOTES section
> rather than the main description. The long-term intent should be that
> script execution this way should work. IIRC this was discussed earlier
> in the thread.

I agree, that something needs to be said. What I instead did was 
added "See BUGS" to the ENOEXEC error, and then this text:

   BUGS
   The  ENOENT  error  described above means that it is not possible
   possible to set the close-on-exec flag  on  the  file  descriptor
   given to a call of the form:

   execveat(fd, "", argv, envp, AT_EMPTY_PATH);

   However, the inability to set the close-on-exec flag means that a
   file descriptor referring to the  script  leaks  through  to  the
   script  itself.  As well as wasting a file descriptor, this leak‐
   age can lead to file-descriptor  exhaustion  in  scenarios  where
   scripts  recursively  employ  exceveat()  (or a future fexecve(3)
   implementation that might be based on execveat()).

Okay?

Thanks,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sched_yield() call on Linux Kernel 2.6.39 is not behaving correct

2015-01-09 Thread Mike Galbraith
On Fri, 2015-01-09 at 11:24 -0800, Yogesh Ahire wrote: 
> Thank you Mike. I didn't get what you mean by saying "its gona try to
> yield for one hell of a long time before it succeeds".

Look at vruntimes.  Equalizing same is what the scheduler does for a
living, it does so by giving the CPU to the runnable task with the
lowest vruntime.  Exec time is scaled by load to become vruntime, but
this vruntime delta is so large you may as well just call it infinity.

-Mike

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


Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Michael Kerrisk (man-pages)
On 01/09/2015 11:13 PM, Eric W. Biederman wrote:
> Rich Felker  writes:
> 
>> On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
> 
>> The "magic open-once magic symlink" approach is really the cleanest
>> solution I can find. In the case where the interpreter does not open
>> the script, nothing terribly bad happens; the magic symlink just
>> sticks around until _exit or exec. In the case where the interpreter
>> opens it more than once, you get a failure, but as far as I know
>> existing interpreters don't do this, and it's arguably bad design. In
>> any case it's a caught error.
> 
> And it doesn't work without introducing security vulnerabilities into
> the kernel, because it breaks close-on-exec semantics.
> 
> All you have to do is pick a file descriptor, good canidates are 0 and
> 255 and make it a convention that that file descriptor is used for
> fexecve.  At least when you want to support scripts.  Otherwise you can
> set close-on-exec.
> 
> That results in no accumulation of file descriptors  because everyone
> always uses the same file descriptor.
> 
> Regardless you don't have a patch and you aren't proposing code and the
> code isn't actually broken so please go away.

Eric,

This style of response isn't helpful. Suggesting that people must have
a patch in hand in order to have a conversation about kernel development
means a lot of clever people are going to be excluded from important
conversations. Those clever people are some user-space developers
who develop the software that the kernel interacts with--you know, the
user-space that is the kernel's raison-d'être.

Rich, as far as I've seen, is one of those clever people--he implemented
and maintains a (pretty much complete?) standard C library, so when he
comes to a conversation like this, I think it's best to start with
the assumption that he's thought long and hard about the problem, and 
seemingly hostile responses as you (and Al) make above don't do much 
to advance the conversation to a solution.

And there is a problem [*] and nothing I've seen so far in this
conversation seems to provide a solution within the current 
kernel implementation (but, maybe I am not clever enough to see it).

==

[*] A summary of the problem for bystanders:

[0.a] Some people want a solution to implementing fexecve() 
  (http://man7.org/linux/man-pages/man3/fexecve.3.html )
  in the absence of /proc (which is currently used for 
  the implementation). The new execveat() is a stepping
  stone to that solution.

[0.b] POSIX permits, but does not require, the FD_CLOEXEC
  (close-on-exec) file descriptor flag to be set on the
  file descriptor passed to fexecve().

[1]   The sequence:
  * Open a script file, to get a descriptor, 'fd'
  * Set the close-on-exec flag on 'fd'
  * execveat(fd, NULL, argv, envp, AT_EMPTY_PATH)

  fails in the execveat() because by the time the script 
  interpreter has been loaded, 'fd' has been closed because
  of the close-on-exec flag.

[2]   Omitting the use of close-on-exec on the FD given to
  fexecve()/execveat() means that the execed script
  receives a superfluous file descriptor that refers to the
  script file. The script cannot determine that there is such 
  an FD or which FD it is without some some messy special-case
  hacking to inspect its environment (and that hacking must be
  based on /proc, AFAICT!)

[3]   Scripts won't do the check in [2], with the result that
  that there'll be descriptor leaks in some cases where
  fexecve()/execveat() is used repeatedly.

[4]   (As Rich points out in a reply to the parent message, the
  solution suggested above of using a fixed file descriptor 
  for fexecve() does not solve the problem either.)

For an example of the leak, consider the following simple program 
and script. The program is just a simple command-line interface to 
exercise execveat():

=
/* t_execveat.c
*/
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 

#define __NR_execveat 322 /* x86-64 */

static int execveat(int dirfd, const char *pathname, char *const argv[],
char *const envp[], int flags)
{
return syscall(__NR_execveat, dirfd, pathname, argv, envp, flags);
}

#define errExit(msg)do { perror(msg); exit(EXIT_FAILURE); \
} while (0)

extern char **environ;

int
main(int argc, char *argv[])
{
int flags, dirfd;
char *path;

flags = 0;

if (argc < 4) {
fprintf(stderr, "%s dirfd-path path argv0 [argvN...]\n", argv[0]);
fprintf(stderr, "\tSpecify 'dirfd' as '-' to get AT_FDCWD\n");
fprintf(stderr, "\tSpecify 'path' as an empty string to get "
"AT_EMPTY_PATH\n");
exit(EXIT_FAILURE);
}

if (argv[1][0] == '-')
dirfd = AT_FDCWD;
else {
dirfd = open(argv[1], O_RDONLY);
if (dirfd == -1)
errExit("open");
}

path 

Re: [PATCH] Documentation: Add entry for dell-laptop sysfs interface

2015-01-09 Thread Darren Hart
On Wed, Dec 31, 2014 at 12:20:59PM +0100, Gabriele Mazzotta wrote:
> On Tuesday 30 December 2014 21:31:49 Brian Norris wrote:
> > Hi,
> > 
> > On Wed, Dec 03, 2014 at 06:41:33PM +0100, Gabriele Mazzotta wrote:
> > > Add the documentation for the new sysfs interface of dell-laptop
> > > that allows to configure the keyboard illumination on Dell systems.
> > > 
> > > Signed-off-by: Gabriele Mazzotta 
> > > Signed-off-by: Pali Rohár 
> > > ---
> > >  .../ABI/testing/sysfs-platform-dell-laptop | 60 
> > > ++
> > >  1 file changed, 60 insertions(+)
> > >  create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop 
> > > b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> > > new file mode 100644
> > > index 000..7969443
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> > > @@ -0,0 +1,60 @@
> > > +What:/sys/class/leds/dell::kbd_backlight/als_setting
> > > +Date:December 2014
> > > +KernelVersion:   3.19
> > > +Contact: Gabriele Mazzotta ,
> > > + Pali Rohár 
> > > +Description:
> > > + This file allows to control the automatic keyboard
> > > + illumination mode on some systems that have an ambient
> > > + light sensor. Write 1 to this file to enable the auto
> > > + mode, 0 to disable it.
> > [...]
> > 
> > This entry appears wrong, or at least incomplete. My system boots with a
> > default value of 18, and the 'set' implementation accepts any value from
> > 0 to 255.
> > 
> > According to the comments in dell-laptop.c, the value actually means
> > something different than on/off:
> > 
> >   cbArg3, byte0  Desired setting of ALS value that turns the light on or 
> > off.
> > 
> > Admittedly, I'm not clear on what the intended interface is, as I've
> > never had the ALS / keyboard backlight controls all working properly on
> > my laptop in the first place, but I thought this would be the right
> > place to ask about getting the documentation and driver in sync.
> 
> Hi,
> 
> You are perfectly right, the documentation is wrong and I'm sorry for
> that. als_setting should allow you to define when the keyboard
> backlight has to be turned on or off depending on the value reported
> by the ambient light sensor.
> 
> Please note that not everything that is in libsmbios [1] is implemented
> in the kernel driver. Take a look at it, recently there have been few
> changes related to the ALS settings. Probably they are not needed given
> that you are able to set the threshold with the current kernel driver,
> but you might find something interesting.
> 
> I'll submit a patch to correct the documentation, thanks for reporting.

Hi Gabriele,

Have I missed a patch from you for this? I'd like to see this corrected in the
3.19 rc cycle.

Thanks,

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


Re: [PATCH 2/2] platform/x86: Add Intel Galileo platform specific setup

2015-01-09 Thread Darren Hart
On Fri, Jan 09, 2015 at 11:17:43AM +, Bryan O'Donoghue wrote:
> On 09/01/15 04:46, Darren Hart wrote:
> >>+   /* Try overlap - IMR_ALIGN */
> >>+   base = base + size - IMR_ALIGN;
> >>+   if (imr_add(base, size, IMR_NON_SMM, IMR_NON_SMM, true) == 0)
> >>+   pr_err(SANITY "overlapped IMR @ (0x%08lx - 0x%08lx)\n",
> >>+  base, base + size);
> >>+}
> >>+#endif
> >
> >I'd rather see this as CONFIG_DEBUG_IMR under Kernel Hacking.
> >
> >What about this sanity test is galileo specific?
> 
> Exactly nothing.
> 
> I think it's a fair point to make this
> * CONFIG_DEBUG_IMR
> * Embedded in the IMR init code
> 
> >>+   /* BIOS releases 0.7.5 and 0.8.0 do not provide DMI strings */
> >>+   if (system_id != NULL) {
> >>+   type = (int)system_id->driver_data;
> >>+   } else {
> >>+   pr_info("Galileo Gen1 BIOS version <= 0.8.0\n");
> >>+   type = GALILEO_QRK_GEN1;
> >
> >So this will load on any Quark device, Galileo or not, that doesn't provide a
> >system_id. Is there any reason we need to support 0.8.0 and earlier firmware?
> 
> Every Galileo Gen1 device ships with firmware version 0.7.5. You can do an
> EFI capsule update to 0.8.0 which still isn't DMI-enabled - or you can go
> and get a firmware greater than 0.9.0 and get DMI strings.
> 
> >I'd prefer not to successfully load a driver on the wrong platform because we
> >assume the user knows what they are doing :-) This effective converts this 
> >from
> >a "platform driver" to a "board file" - the bad kind.
> 
> That would be a problem if there were any other X1000 boards that don't
> provide DMI strings but only Galileo Gen1 out of the box is DMI deprived, so
> for that reason I think falling back to assume Gen1 when you've identified a
> Quark X1000 is the right thing to do.
> 
> Right now the only Quark X1000 devices that real users in the field have are
> Galileo boards which either identify with DMI strings (Gen2 and upgraded
> Gen1 boards) - or don't identify with DMI strings Gen1 @ 0.7.5 and 0.8.0
> 
> Also consider that any new X1000 based systems running Linux will be based
> on the latest reference firmware from Intel which provides DMI identifiers,
> so Galileo Gen3 if it is in the making will have a DMI string to identify
> itself as a Gen3, same with a Gen2 and upgraded Gen1.
> 
> The only X1000 based boards without DMI strings are going to be Galileo Gen1
> devices @ firmware version 0.7.5 and 0.8.0, so I don't think we will end up
> in a situation of loading the wrong platform code, rather we'll accommodate
> the older firmware this way
> 
> All that said - there *is* an alternative for 0.7.5 and 0.8.0 firmware but,
> I know you won't like it.
> 
> Prior to 0.9.0 firmware Galileo boards were identified by
> 
> 1. Mapping a section of SPI flash
> 2. Finding a specific header at a know location on SPI flash
> 3. Extracting a unique platform ID field from that header
> 4. Examining that platform ID field and loading Galileo specific drivers if
> found
> 
> So in theory we could go this route if you feel that fallback the fallback
> described above isn't robust enough.
> 
> I'm OK to add that code in for V2 and we can decide which is the more
> desirable way to do it - fallback or extract of platform id from SPI flash
> and then finalise at V3

I'm wondering if there is a need for this to be a platform driver at
all. Could we, instead, tear down any unlocked IMRs at boot as part of the IMR
driver itself, as well as lock the kernel .text. Firmware has the option of
making an IMR mandatory by locking it. If it isn't locked, what use is it to the
OS without a lot more context? Any sort of policy enforced with IMRs is a
user-space decision, so clearing out the unlocked ones and then handing off to
user-space seems like a sane default mode to me.

I discussed this with Boon Leong this afternoon and we couldn't come up with a
justification for a platform-specific driver to do what this does.

Cc'ing Mel for his thoughts on the VM bit.
Cc'ing Matthew for his take on platform driver appropriateness.

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


Re: [PATCH 5/6] HMM: add per mirror page table.

2015-01-09 Thread Jerome Glisse
On Thu, Jan 08, 2015 at 01:05:41PM +0200, Haggai Eran wrote:
> On 06/01/2015 00:44, j.gli...@gmail.com wrote:
> > +   /* fence_wait() - to wait on device driver fence.
> > +*
> > +* @fence: The device driver fence struct.
> > +* Returns: 0 on success,-EIO on error, -EAGAIN to wait again.
> > +*
> > +* Called when hmm want to wait for all operations associated with a
> > +* fence to complete (including device cache flush if the event mandate
> > +* it).
> > +*
> > +* Device driver must free fence and associated resources if it returns
> > +* something else thant -EAGAIN. On -EAGAIN the fence must not be free
> > +* as hmm will call back again.
> > +*
> > +* Return error if scheduled operation failed or if need to wait again.
> > +* -EIO Some input/output error with the device.
> > +* -EAGAIN The fence not yet signaled, hmm reschedule waiting thread.
> > +*
> > +* All other return value trigger warning and are transformed to -EIO.
> > +*/
> > +   int (*fence_wait)(struct hmm_fence *fence);
> 
> According to the comment, the device frees the fence struct when the
> fence_wait callback returns zero or -EIO, but the code below calls
> fence_unref after fence_wait on the same fence.

Yes comment is out of date, i wanted to simplify fence before readding
it once needed (by device memory migration).

> 
> > +
> > +   /* fence_ref() - take a reference fence structure.
> > +*
> > +* @fence: Fence structure hmm is referencing.
> > +*/
> > +   void (*fence_ref)(struct hmm_fence *fence);
> 
> I don't see fence_ref being called anywhere in the patchset. Is it
> actually needed?

Not right now but the page migration to device memory use it. But i
can remove it now.

I can respin to make comment match code but i would like to know where
i stand on everythings else.

Cheers,
Jérôme

> 
> > +static void hmm_device_fence_wait(struct hmm_device *device,
> > + struct hmm_fence *fence)
> > +{
> > +   struct hmm_mirror *mirror;
> > +   int r;
> > +
> > +   if (fence == NULL)
> > +   return;
> > +
> > +   list_del_init(>list);
> > +   do {
> > +   r = device->ops->fence_wait(fence);
> > +   if (r == -EAGAIN)
> > +   io_schedule();
> > +   } while (r == -EAGAIN);
> > +
> > +   mirror = fence->mirror;
> > +   device->ops->fence_unref(fence);
> > +   if (r)
> > +   hmm_mirror_release(mirror);
> > +}
> > +
> 
> Regards,
> Haggai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 5/6] Drivers: hv: vmbus: Fix a bug in vmbus_establish_gpadl()

2015-01-09 Thread K. Y. Srinivasan
Correctly compute the local (gpadl) handle.
I would like to thank Michael Brown  for seeing this bug.

Signed-off-by: K. Y. Srinivasan 
Reported-by: Michael Brown 
---
 drivers/hv/channel.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 433f72a..c76ffbe 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -366,8 +366,8 @@ int vmbus_establish_gpadl(struct vmbus_channel *channel, 
void *kbuffer,
unsigned long flags;
int ret = 0;
 
-   next_gpadl_handle = atomic_read(_connection.next_gpadl_handle);
-   atomic_inc(_connection.next_gpadl_handle);
+   next_gpadl_handle =
+   (atomic_inc_return(_connection.next_gpadl_handle) - 1);
 
ret = create_gpadl_header(kbuffer, size, , );
if (ret)
-- 
1.7.4.1

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


[PATCH RESEND 2/6] Drivers: hv: hv_balloon: Fix a locking bug in the balloon driver

2015-01-09 Thread K. Y. Srinivasan
We support memory hot-add in the Hyper-V balloon driver by hot adding an 
appropriately
sized and aligned region and controlling the on-lining of pages within that 
region
based on the pages that the host wants us to online. We do this because the
granularity and alignment requirements in Linux are different from what Windows
expects. The state to manage the onlining of pages needs to be correctly
protected. Fix this bug.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c |   68 +++---
 1 files changed, 63 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 9cbbb83..8e30415 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -533,6 +533,9 @@ struct hv_dynmem_device {
 */
struct task_struct *thread;
 
+   struct mutex ha_region_mutex;
+   struct completion waiter_event;
+
/*
 * A list of hot-add regions.
 */
@@ -549,7 +552,59 @@ struct hv_dynmem_device {
 static struct hv_dynmem_device dm_device;
 
 static void post_status(struct hv_dynmem_device *dm);
+
 #ifdef CONFIG_MEMORY_HOTPLUG
+static void acquire_region_mutex(bool trylock)
+{
+   if (trylock) {
+   reinit_completion(_device.waiter_event);
+   while (!mutex_trylock(_device.ha_region_mutex))
+   wait_for_completion(_device.waiter_event);
+   } else {
+   mutex_lock(_device.ha_region_mutex);
+   }
+}
+
+static void release_region_mutex(bool trylock)
+{
+   if (trylock) {
+   mutex_unlock(_device.ha_region_mutex);
+   } else {
+   mutex_unlock(_device.ha_region_mutex);
+   complete(_device.waiter_event);
+   }
+}
+
+static int hv_memory_notifier(struct notifier_block *nb, unsigned long val,
+ void *v)
+{
+   switch (val) {
+   case MEM_GOING_ONLINE:
+   acquire_region_mutex(true);
+   break;
+
+   case MEM_ONLINE:
+   case MEM_CANCEL_ONLINE:
+   release_region_mutex(true);
+   if (dm_device.ha_waiting) {
+   dm_device.ha_waiting = false;
+   complete(_device.ol_waitevent);
+   }
+   break;
+
+   case MEM_GOING_OFFLINE:
+   case MEM_OFFLINE:
+   case MEM_CANCEL_OFFLINE:
+   break;
+   }
+   return NOTIFY_OK;
+}
+
+static struct notifier_block hv_memory_nb = {
+   .notifier_call = hv_memory_notifier,
+   .priority = 0
+};
+
 
 static void hv_bring_pgs_online(unsigned long start_pfn, unsigned long size)
 {
@@ -591,6 +646,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
long size,
init_completion(_device.ol_waitevent);
dm_device.ha_waiting = true;
 
+   release_region_mutex(false);
nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
ret = add_memory(nid, PFN_PHYS((start_pfn)),
(HA_CHUNK << PAGE_SHIFT));
@@ -619,6 +675,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
long size,
 * have not been "onlined" within the allowed time.
 */
wait_for_completion_timeout(_device.ol_waitevent, 5*HZ);
+   acquire_region_mutex(false);
post_status(_device);
}
 
@@ -632,11 +689,6 @@ static void hv_online_page(struct page *pg)
unsigned long cur_start_pgp;
unsigned long cur_end_pgp;
 
-   if (dm_device.ha_waiting) {
-   dm_device.ha_waiting = false;
-   complete(_device.ol_waitevent);
-   }
-
list_for_each(cur, _device.ha_region_list) {
has = list_entry(cur, struct hv_hotadd_state, list);
cur_start_pgp = (unsigned long)
@@ -834,6 +886,7 @@ static void hot_add_req(struct work_struct *dummy)
resp.hdr.size = sizeof(struct dm_hot_add_response);
 
 #ifdef CONFIG_MEMORY_HOTPLUG
+   acquire_region_mutex(false);
pg_start = dm->ha_wrk.ha_page_range.finfo.start_page;
pfn_cnt = dm->ha_wrk.ha_page_range.finfo.page_cnt;
 
@@ -865,6 +918,7 @@ static void hot_add_req(struct work_struct *dummy)
if (do_hot_add)
resp.page_count = process_hot_add(pg_start, pfn_cnt,
rg_start, rg_sz);
+   release_region_mutex(false);
 #endif
/*
 * The result field of the response structure has the
@@ -1388,7 +1442,9 @@ static int balloon_probe(struct hv_device *dev,
dm_device.next_version = DYNMEM_PROTOCOL_VERSION_WIN7;
init_completion(_device.host_event);
init_completion(_device.config_event);
+   init_completion(_device.waiter_event);
INIT_LIST_HEAD(_device.ha_region_list);
+   mutex_init(_device.ha_region_mutex);
INIT_WORK(_device.balloon_wrk.wrk, balloon_up);

[PATCH RESEND 1/6] Drivers: hv: hv_balloon: Make adjustments in computing the floor

2015-01-09 Thread K. Y. Srinivasan
Make adjustments in computing the balloon floor. The current computation
of the balloon floor was not appropriate for virtual machines with more than
10 GB of assigned memory - we would get into situations where the host would
agressively balloon down the guest and leave the guest in an unusable state.
This patch fixes the issue by raising the floor.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b958ded..9cbbb83 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -928,9 +928,8 @@ static unsigned long compute_balloon_floor(void)
 * 12872(1/2)
 * 512   168(1/4)
 *2048   360(1/8)
-*8192   552(1/32)
-*   32768  1320
-*  131072  4392
+*8192   768(1/16)
+*   32768  1536(1/32)
 */
if (totalram_pages < MB2PAGES(128))
min_pages = MB2PAGES(8) + (totalram_pages >> 1);
@@ -938,8 +937,10 @@ static unsigned long compute_balloon_floor(void)
min_pages = MB2PAGES(40) + (totalram_pages >> 2);
else if (totalram_pages < MB2PAGES(2048))
min_pages = MB2PAGES(104) + (totalram_pages >> 3);
+   else if (totalram_pages < MB2PAGES(8192))
+   min_pages = MB2PAGES(256) + (totalram_pages >> 4);
else
-   min_pages = MB2PAGES(296) + (totalram_pages >> 5);
+   min_pages = MB2PAGES(512) + (totalram_pages >> 5);
 #undef MB2PAGES
return min_pages;
 }
-- 
1.7.4.1

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


[PATCH RESEND 3/6] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context

2015-01-09 Thread K. Y. Srinivasan
We currently release memory (balloon down) in the interrupt context and we also
post memory status while releasing memory. Rather than posting the status
in the interrupt context, wakeup the status posting thread to post the status.
This will address the inconsistent lock state that Sitsofe Wheeler 

reported:

http://lkml.iu.edu/hypermail/linux/kernel/1411.1/00075.html

Signed-off-by: K. Y. Srinivasan 
Reported-by: Sitsofe Wheeler 
---
 drivers/hv/hv_balloon.c |   11 ---
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 8e30415..ff16938 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1226,7 +1226,7 @@ static void balloon_down(struct hv_dynmem_device *dm,
 
for (i = 0; i < range_count; i++) {
free_balloon_pages(dm, _array[i]);
-   post_status(_device);
+   complete(_device.config_event);
}
 
if (req->more_pages == 1)
@@ -1250,19 +1250,16 @@ static void balloon_onchannelcallback(void *context);
 static int dm_thread_func(void *dm_dev)
 {
struct hv_dynmem_device *dm = dm_dev;
-   int t;
 
while (!kthread_should_stop()) {
-   t = wait_for_completion_interruptible_timeout(
+   wait_for_completion_interruptible_timeout(
_device.config_event, 1*HZ);
/*
 * The host expects us to post information on the memory
 * pressure every second.
 */
-
-   if (t == 0)
-   post_status(dm);
-
+   reinit_completion(_device.config_event);
+   post_status(dm);
}
 
return 0;
-- 
1.7.4.1

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


[PATCH RESEND 4/6] Drivers: hv: vmbus: Implement a clockevent device

2015-01-09 Thread K. Y. Srinivasan
Implement a clockevent device based on the timer support available on
Hyper-V.
In this version of the patch I have addressed Jason's review comments.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Jason Wang 
---
 arch/x86/include/uapi/asm/hyperv.h |   11 +
 drivers/hv/hv.c|   78 
 drivers/hv/hyperv_vmbus.h  |   21 ++
 drivers/hv/vmbus_drv.c |   37 -
 4 files changed, 145 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/uapi/asm/hyperv.h 
b/arch/x86/include/uapi/asm/hyperv.h
index 462efe7..90c458e 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -187,6 +187,17 @@
 #define HV_X64_MSR_SINT14  0x409E
 #define HV_X64_MSR_SINT15  0x409F
 
+/*
+ * Synthetic Timer MSRs. Four timers per vcpu.
+ */
+#define HV_X64_MSR_STIMER0_CONFIG  0x40B0
+#define HV_X64_MSR_STIMER0_COUNT   0x40B1
+#define HV_X64_MSR_STIMER1_CONFIG  0x40B2
+#define HV_X64_MSR_STIMER1_COUNT   0x40B3
+#define HV_X64_MSR_STIMER2_CONFIG  0x40B4
+#define HV_X64_MSR_STIMER2_COUNT   0x40B5
+#define HV_X64_MSR_STIMER3_CONFIG  0x40B6
+#define HV_X64_MSR_STIMER3_COUNT   0x40B7
 
 #define HV_X64_MSR_HYPERCALL_ENABLE0x0001
 #define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT12
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 3e4235c..50e51a5 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -28,7 +28,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include "hyperv_vmbus.h"
 
 /* The one and only */
@@ -37,6 +39,10 @@ struct hv_context hv_context = {
.hypercall_page = NULL,
 };
 
+#define HV_TIMER_FREQUENCY (10 * 1000 * 1000) /* 100ns period */
+#define HV_MAX_MAX_DELTA_TICKS 0x
+#define HV_MIN_DELTA_TICKS 1
+
 /*
  * query_hypervisor_info - Get version info of the windows hypervisor
  */
@@ -144,6 +150,8 @@ int hv_init(void)
   sizeof(int) * NR_CPUS);
memset(hv_context.event_dpc, 0,
   sizeof(void *) * NR_CPUS);
+   memset(hv_context.clk_evt, 0,
+  sizeof(void *) * NR_CPUS);
 
max_leaf = query_hypervisor_info();
 
@@ -258,10 +266,63 @@ u16 hv_signal_event(void *con_id)
return status;
 }
 
+static int hv_ce_set_next_event(unsigned long delta,
+   struct clock_event_device *evt)
+{
+   cycle_t current_tick;
+
+   WARN_ON(evt->mode != CLOCK_EVT_MODE_ONESHOT);
+
+   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
+   current_tick += delta;
+   wrmsrl(HV_X64_MSR_STIMER0_COUNT, current_tick);
+   return 0;
+}
+
+static void hv_ce_setmode(enum clock_event_mode mode,
+ struct clock_event_device *evt)
+{
+   union hv_timer_config timer_cfg;
+
+   switch (mode) {
+   case CLOCK_EVT_MODE_PERIODIC:
+   /* unsupported */
+   break;
+
+   case CLOCK_EVT_MODE_ONESHOT:
+   timer_cfg.enable = 1;
+   timer_cfg.auto_enable = 1;
+   timer_cfg.sintx = VMBUS_MESSAGE_SINT;
+   wrmsrl(HV_X64_MSR_STIMER0_CONFIG, timer_cfg.as_uint64);
+   break;
+
+   case CLOCK_EVT_MODE_UNUSED:
+   case CLOCK_EVT_MODE_SHUTDOWN:
+   wrmsrl(HV_X64_MSR_STIMER0_COUNT, 0);
+   wrmsrl(HV_X64_MSR_STIMER0_CONFIG, 0);
+   break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
+   }
+}
+
+static void hv_init_clockevent_device(struct clock_event_device *dev, int cpu)
+{
+   dev->name = "Hyper-V clockevent";
+   dev->features = CLOCK_EVT_FEAT_ONESHOT;
+   dev->cpumask = cpumask_of(cpu);
+   dev->rating = 1000;
+   dev->owner = THIS_MODULE;
+
+   dev->set_mode = hv_ce_setmode;
+   dev->set_next_event = hv_ce_set_next_event;
+}
+
 
 int hv_synic_alloc(void)
 {
size_t size = sizeof(struct tasklet_struct);
+   size_t ced_size = sizeof(struct clock_event_device);
int cpu;
 
for_each_online_cpu(cpu) {
@@ -272,6 +333,13 @@ int hv_synic_alloc(void)
}
tasklet_init(hv_context.event_dpc[cpu], vmbus_on_event, cpu);
 
+   hv_context.clk_evt[cpu] = kzalloc(ced_size, GFP_ATOMIC);
+   if (hv_context.clk_evt[cpu] == NULL) {
+   pr_err("Unable to allocate clock event device\n");
+   goto err;
+   }
+   hv_init_clockevent_device(hv_context.clk_evt[cpu], cpu);
+
hv_context.synic_message_page[cpu] =
(void *)get_zeroed_page(GFP_ATOMIC);
 
@@ -305,6 +373,7 @@ err:
 static void hv_synic_free_cpu(int cpu)
 {
kfree(hv_context.event_dpc[cpu]);
+   kfree(hv_context.clk_evt[cpu]);
if 

[PATCH RESEND 6/6] Drivers: hv: vmbus: Support a vmbus API for efficiently sending page arrays

2015-01-09 Thread K. Y. Srinivasan
Currently, the API for sending a multi-page buffer over VMBUS is limited to
a maximum pfn array of MAX_MULTIPAGE_BUFFER_COUNT. This limitation is
not imposed by the host and unnecessarily limits the maximum payload
that can be sent. Implement an API that does not have this restriction.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel.c   |   44 
 include/linux/hyperv.h |   31 +++
 2 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index c76ffbe..18c4f23 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -686,6 +686,50 @@ EXPORT_SYMBOL_GPL(vmbus_sendpacket_pagebuffer);
 /*
  * vmbus_sendpacket_multipagebuffer - Send a multi-page buffer packet
  * using a GPADL Direct packet type.
+ * The buffer includes the vmbus descriptor.
+ */
+int vmbus_sendpacket_mpb_desc(struct vmbus_channel *channel,
+ struct vmbus_packet_mpb_array *desc,
+ u32 desc_size,
+ void *buffer, u32 bufferlen, u64 requestid)
+{
+   int ret;
+   u32 packetlen;
+   u32 packetlen_aligned;
+   struct kvec bufferlist[3];
+   u64 aligned_data = 0;
+   bool signal = false;
+
+   packetlen = desc_size + bufferlen;
+   packetlen_aligned = ALIGN(packetlen, sizeof(u64));
+
+   /* Setup the descriptor */
+   desc->type = VM_PKT_DATA_USING_GPA_DIRECT;
+   desc->flags = VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED;
+   desc->dataoffset8 = desc_size >> 3; /* in 8-bytes grandularity */
+   desc->length8 = (u16)(packetlen_aligned >> 3);
+   desc->transactionid = requestid;
+   desc->rangecount = 1;
+
+   bufferlist[0].iov_base = desc;
+   bufferlist[0].iov_len = desc_size;
+   bufferlist[1].iov_base = buffer;
+   bufferlist[1].iov_len = bufferlen;
+   bufferlist[2].iov_base = _data;
+   bufferlist[2].iov_len = (packetlen_aligned - packetlen);
+
+   ret = hv_ringbuffer_write(>outbound, bufferlist, 3, );
+
+   if (ret == 0 && signal)
+   vmbus_setevent(channel);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(vmbus_sendpacket_mpb_desc);
+
+/*
+ * vmbus_sendpacket_multipagebuffer - Send a multi-page buffer packet
+ * using a GPADL Direct packet type.
  */
 int vmbus_sendpacket_multipagebuffer(struct vmbus_channel *channel,
struct hv_multipage_buffer *multi_pagebuffer,
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 476c685..259023a 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -57,6 +57,18 @@ struct hv_multipage_buffer {
u64 pfn_array[MAX_MULTIPAGE_BUFFER_COUNT];
 };
 
+/*
+ * Multiple-page buffer array; the pfn array is variable size:
+ * The number of entries in the PFN array is determined by
+ * "len" and "offset".
+ */
+struct hv_mpb_array {
+   /* Length and Offset determines the # of pfns in the array */
+   u32 len;
+   u32 offset;
+   u64 pfn_array[];
+};
+
 /* 0x18 includes the proprietary packet header */
 #define MAX_PAGE_BUFFER_PACKET (0x18 + \
(sizeof(struct hv_page_buffer) * \
@@ -814,6 +826,18 @@ struct vmbus_channel_packet_multipage_buffer {
struct hv_multipage_buffer range;
 } __packed;
 
+/* The format must be the same as struct vmdata_gpa_direct */
+struct vmbus_packet_mpb_array {
+   u16 type;
+   u16 dataoffset8;
+   u16 length8;
+   u16 flags;
+   u64 transactionid;
+   u32 reserved;
+   u32 rangecount; /* Always 1 in this case */
+   struct hv_mpb_array range;
+} __packed;
+
 
 extern int vmbus_open(struct vmbus_channel *channel,
u32 send_ringbuffersize,
@@ -845,6 +869,13 @@ extern int vmbus_sendpacket_multipagebuffer(struct 
vmbus_channel *channel,
u32 bufferlen,
u64 requestid);
 
+extern int vmbus_sendpacket_mpb_desc(struct vmbus_channel *channel,
+struct vmbus_packet_mpb_array *mpb,
+u32 desc_size,
+void *buffer,
+u32 bufferlen,
+u64 requestid);
+
 extern int vmbus_establish_gpadl(struct vmbus_channel *channel,
  void *kbuffer,
  u32 size,
-- 
1.7.4.1

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


[PATCH RESEND 0/6] Drivers: hv: Miscellaneous fixes and enhancements

2015-01-09 Thread K. Y. Srinivasan
In addition to some miscellaneous bug fixes and enhancements
implement a clockevent device based on the functionality supported by Hyper-V.

K. Y. Srinivasan (6):
  Drivers: hv: hv_balloon: Make adjustments in computing the floor
  Drivers: hv: hv_balloon: Fix a locking bug in the balloon driver
  Drivers: hv: hv_balloon: Don't post pressure status from interrupt
context
  Drivers: hv: vmbus: Implement a clockevent device
  Drivers: hv: vmbus: Fix a bug in vmbus_establish_gpadl()
  Drivers: hv: vmbus: Support a vmbus API for efficiently sending page
arrays

 arch/x86/include/uapi/asm/hyperv.h |   11 +
 drivers/hv/channel.c   |   48 +++-
 drivers/hv/hv.c|   78 +++
 drivers/hv/hv_balloon.c|   88 +---
 drivers/hv/hyperv_vmbus.h  |   21 +
 drivers/hv/vmbus_drv.c |   40 +++-
 include/linux/hyperv.h |   31 +
 7 files changed, 297 insertions(+), 20 deletions(-)

-- 
1.7.4.1

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


Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Rich Felker
On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 10:41:44PM -0500, Rich Felker wrote:
> > > _After_ the traversal it's too late to do this sort of thing - after all,
> > > how do you tell if your current position had been set by the traversal of
> > > your symlink or that of any normal /proc/self/fd/?
> > 
> > Thanks for clarifying how this all works in the kernel. It makes it
> > easier to understand what the costs (especially complexity costs) of
> > different implementation options might be for the kernel.
> > 
> > > And doing that _during_ the traversal would really suck - stray ls -lR 
> > > /proc
> > > could race with that open() done by script interpreter.
> > 
> > IMO this one issue is easily solvable by limiting the special action
> > to calls by the owning pid.
> 
> Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
> etc.) before bothering with open(2), you'll get screwed.

Yes, but I think that would be very bad interpreter design.
stat/getxattr/access/whatever followed by open is always a TOCTOU
race. The correct sequence of actions is always open followed by
fstat/fgetxattr/...

> Moreover, if it
> does so only in case when you have something specific in environment,
> you'll have the devil of the time trying to figure out how to reproduce
> such a bug report...

Yes, this is a more serious concern. For example, if a shell processes
$HISTFILE or something before opening the script. I'm starting to
prefer the idea of just refusing to honor the close-on-exec flag for
the fd passed to fexecve but preserving it, and letting the
interpreter close the file itself if it wants to. This could be done
with or without the new auxv entry stuff.

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


[PATCH 07/25] staging: line6: Key off of device type

2015-01-09 Thread Chris Rorvick
The driver currently uses the device's idProduct as input to several
switch statements.  In some cases this is not sufficiently granular and
the interface number must be taken into account.

Store the device type in `usb_line6' and key off of it instead.  New
types can then be added that map to specific interfaces on the device so
that this conditional logic can be flattened out.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c   | 203 ---
 drivers/staging/line6/driver.h   |   4 +-
 drivers/staging/line6/pcm.c  |  38 
 drivers/staging/line6/toneport.c |  42 
 4 files changed, 144 insertions(+), 143 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index c090b2b..81d5a27 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -363,23 +363,23 @@ static void line6_data_received(struct urb *urb)
line6->message_length = done;
line6_midi_receive(line6, line6->buffer_message, done);
 
-   switch (le16_to_cpu(line6->usbdev->descriptor.idProduct)) {
-   case LINE6_DEVID_BASSPODXT:
-   case LINE6_DEVID_BASSPODXTLIVE:
-   case LINE6_DEVID_BASSPODXTPRO:
-   case LINE6_DEVID_PODXT:
-   case LINE6_DEVID_PODXTPRO:
-   case LINE6_DEVID_POCKETPOD:
+   switch (line6->type) {
+   case LINE6_BASSPODXT:
+   case LINE6_BASSPODXTLIVE:
+   case LINE6_BASSPODXTPRO:
+   case LINE6_PODXT:
+   case LINE6_PODXTPRO:
+   case LINE6_POCKETPOD:
line6_pod_process_message((struct usb_line6_pod *)
  line6);
break;
 
-   case LINE6_DEVID_PODHD300:
-   case LINE6_DEVID_PODHD400:
-   case LINE6_DEVID_PODHD500:
+   case LINE6_PODHD300:
+   case LINE6_PODHD400:
+   case LINE6_PODHD500:
break; /* let userspace handle MIDI */
 
-   case LINE6_DEVID_PODXTLIVE:
+   case LINE6_PODXTLIVE:
switch (line6->interface_number) {
case PODXTLIVE_INTERFACE_POD:
line6_pod_process_message((struct usb_line6_pod
@@ -399,7 +399,7 @@ static void line6_data_received(struct urb *urb)
}
break;
 
-   case LINE6_DEVID_VARIAX:
+   case LINE6_VARIAX:
line6_variax_process_message((struct usb_line6_variax *)
 line6);
break;
@@ -629,7 +629,6 @@ static int line6_probe(struct usb_interface *interface,
struct usb_line6 *line6;
const struct line6_properties *properties;
int interface_number, alternate = 0;
-   int product;
int size = 0;
int ep_read = 0, ep_write = 0;
int ret;
@@ -651,19 +650,18 @@ static int line6_probe(struct usb_interface *interface,
/* initialize device info: */
properties = _properties_table[devtype];
dev_info(>dev, "Line6 %s found\n", properties->name);
-   product = le16_to_cpu(usbdev->descriptor.idProduct);
 
/* query interface number */
interface_number = interface->cur_altsetting->desc.bInterfaceNumber;
 
-   switch (product) {
-   case LINE6_DEVID_BASSPODXTLIVE:
-   case LINE6_DEVID_PODXTLIVE:
-   case LINE6_DEVID_VARIAX:
+   switch (devtype) {
+   case LINE6_BASSPODXTLIVE:
+   case LINE6_PODXTLIVE:
+   case LINE6_VARIAX:
alternate = 1;
break;
 
-   case LINE6_DEVID_POCKETPOD:
+   case LINE6_POCKETPOD:
switch (interface_number) {
case 0:
return -ENODEV; /* this interface has no endpoints */
@@ -675,7 +673,7 @@ static int line6_probe(struct usb_interface *interface,
}
break;
 
-   case LINE6_DEVID_PODHD500:
+   case LINE6_PODHD500:
switch (interface_number) {
case 0:
alternate = 1;
@@ -688,25 +686,25 @@ static int line6_probe(struct usb_interface *interface,
}
break;
 
-   case LINE6_DEVID_BASSPODXT:
-   case LINE6_DEVID_BASSPODXTPRO:
-   case LINE6_DEVID_PODXT:
-   case LINE6_DEVID_PODXTPRO:
-   case LINE6_DEVID_PODHD300:
-   case LINE6_DEVID_PODHD400:
+   case LINE6_BASSPODXT:
+   case LINE6_BASSPODXTPRO:
+   case LINE6_PODXT:
+   case LINE6_PODXTPRO:
+   case LINE6_PODHD300:
+   case LINE6_PODHD400:
alternate = 5;
break;
 
-   case LINE6_DEVID_GUITARPORT:
-   case LINE6_DEVID_PODSTUDIO_GX:
-   case 

[PATCH 03/25] staging: line6: Remove unsupported X3 devices

2015-01-09 Thread Chris Rorvick
Support for these devices appears to have never been completed.  Remove
them from the device table along with a minimal amount of supporting
code.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c  | 26 --
 drivers/staging/line6/pcm.c |  2 --
 drivers/staging/line6/usbdefs.h |  2 --
 3 files changed, 30 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 15f3bc4..e40400b 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -43,8 +43,6 @@ static const struct usb_device_id line6_id_table[] = {
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_GX)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_UX1)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_UX2)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODX3)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODX3LIVE)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODXT)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODXTLIVE)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODXTPRO)},
@@ -74,8 +72,6 @@ static const struct line6_properties line6_properties_table[] 
= {
L6PROP("PODStudioGX",   "POD Studio GX",PCM),
L6PROP("PODStudioUX1",  "POD Studio UX1",   PCM),
L6PROP("PODStudioUX2",  "POD Studio UX2",   PCM),
-   L6PROP("PODX3", "POD X3",   PCM),
-   L6PROP("PODX3Live", "POD X3 Live",  PCM),
L6PROP("PODxt", "PODxt",CTRL_PCM_HW),
L6PROP("PODxtLive", "PODxt Live",   CTRL_PCM_HW),
L6PROP("PODxtPro",  "PODxt Pro",CTRL_PCM_HW),
@@ -673,8 +669,6 @@ static int line6_probe(struct usb_interface *interface,
break;
 
case LINE6_DEVID_PODHD500:
-   case LINE6_DEVID_PODX3:
-   case LINE6_DEVID_PODX3LIVE:
switch (interface_number) {
case 0:
alternate = 1;
@@ -765,14 +759,6 @@ static int line6_probe(struct usb_interface *interface,
ep_write = 0x02;
break;
 
-   case LINE6_DEVID_PODX3:
-   case LINE6_DEVID_PODX3LIVE:
-   /* currently unused! */
-   size = sizeof(struct usb_line6_pod);
-   ep_read = 0x81;
-   ep_write = 0x01;
-   break;
-
case LINE6_DEVID_PODSTUDIO_GX:
case LINE6_DEVID_PODSTUDIO_UX1:
case LINE6_DEVID_PODSTUDIO_UX2:
@@ -898,8 +884,6 @@ static int line6_probe(struct usb_interface *interface,
case LINE6_DEVID_BASSPODXTLIVE:
case LINE6_DEVID_BASSPODXTPRO:
case LINE6_DEVID_POCKETPOD:
-   case LINE6_DEVID_PODX3:
-   case LINE6_DEVID_PODX3LIVE:
case LINE6_DEVID_PODXT:
case LINE6_DEVID_PODXTPRO:
ret = line6_pod_init(interface, (struct usb_line6_pod *)line6);
@@ -971,14 +955,6 @@ static int line6_probe(struct usb_interface *interface,
dev_info(>dev, "Line6 %s now attached\n",
 line6->properties->name);
 
-   switch (product) {
-   case LINE6_DEVID_PODX3:
-   case LINE6_DEVID_PODX3LIVE:
-   dev_info(>dev,
-"NOTE: the Line6 %s is detected, but not yet 
supported\n",
-line6->properties->name);
-   }
-
/* increment reference counters: */
usb_get_intf(interface);
usb_get_dev(usbdev);
@@ -1026,8 +1002,6 @@ static void line6_disconnect(struct usb_interface 
*interface)
case LINE6_DEVID_BASSPODXTLIVE:
case LINE6_DEVID_BASSPODXTPRO:
case LINE6_DEVID_POCKETPOD:
-   case LINE6_DEVID_PODX3:
-   case LINE6_DEVID_PODX3LIVE:
case LINE6_DEVID_PODXT:
case LINE6_DEVID_PODXTPRO:
line6_pod_disconnect(interface);
diff --git a/drivers/staging/line6/pcm.c b/drivers/staging/line6/pcm.c
index a3136b1..076c87b 100644
--- a/drivers/staging/line6/pcm.c
+++ b/drivers/staging/line6/pcm.c
@@ -442,8 +442,6 @@ int line6_init_pcm(struct usb_line6 *line6,
break;
 
case LINE6_DEVID_PODHD500:
-   case LINE6_DEVID_PODX3:
-   case LINE6_DEVID_PODX3LIVE:
ep_read = 0x86;
ep_write = 0x02;
break;
diff --git a/drivers/staging/line6/usbdefs.h b/drivers/staging/line6/usbdefs.h
index 2bc2fe7..06bf909 100644
--- a/drivers/staging/line6/usbdefs.h
+++ b/drivers/staging/line6/usbdefs.h
@@ -30,8 +30,6 @@
 #define LINE6_DEVID_PODSTUDIO_GX  0x4153
 #define LINE6_DEVID_PODSTUDIO_UX1 0x4150
 #define LINE6_DEVID_PODSTUDIO_UX2 0x4151
-#define LINE6_DEVID_PODX3 0x414a
-#define LINE6_DEVID_PODX3LIVE 0x414b
 #define LINE6_DEVID_PODXT 0x5044
 #define LINE6_DEVID_PODXTLIVE 0x4650
 #define LINE6_DEVID_PODXTPRO  0x5050
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body 

[PATCH 08/25] staging: line6: Remove idVendor and idProduct macros

2015-01-09 Thread Chris Rorvick
These are now only used to build the device table.  Each entry in this
table is already clearly documented as to what device it maps to so the
macros become unnecessary indirection.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c  | 56 ++---
 drivers/staging/line6/usbdefs.h | 24 --
 2 files changed, 19 insertions(+), 61 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 81d5a27..6dc8a0d 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -30,46 +30,28 @@
 #define DRIVER_DESC"Line6 USB Driver"
 #define DRIVER_VERSION "0.9.1beta" DRIVER_REVISION
 
-#define LINE6_DEVICE(prod) USB_DEVICE(LINE6_VENDOR_ID, prod)
+#define LINE6_DEVICE(prod) USB_DEVICE(0x0e41, prod)
 
 /* table of devices that work with this driver */
 static const struct usb_device_id line6_id_table[] = {
-   { LINE6_DEVICE(LINE6_DEVID_BASSPODXT),
-   .driver_info = LINE6_BASSPODXT },
-   { LINE6_DEVICE(LINE6_DEVID_BASSPODXTLIVE),
-   .driver_info = LINE6_BASSPODXTLIVE },
-   { LINE6_DEVICE(LINE6_DEVID_BASSPODXTPRO),
-   .driver_info = LINE6_BASSPODXTPRO },
-   { LINE6_DEVICE(LINE6_DEVID_GUITARPORT),
-   .driver_info = LINE6_GUITARPORT },
-   { LINE6_DEVICE(LINE6_DEVID_POCKETPOD),
-   .driver_info = LINE6_POCKETPOD },
-   { LINE6_DEVICE(LINE6_DEVID_PODHD300),
-   .driver_info = LINE6_PODHD300 },
-   { LINE6_DEVICE(LINE6_DEVID_PODHD400),
-   .driver_info = LINE6_PODHD400 },
-   { LINE6_DEVICE(LINE6_DEVID_PODHD500),
-   .driver_info = LINE6_PODHD500 },
-   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_GX),
-   .driver_info = LINE6_PODSTUDIO_GX },
-   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_UX1),
-   .driver_info = LINE6_PODSTUDIO_UX1 },
-   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_UX2),
-   .driver_info = LINE6_PODSTUDIO_UX2 },
-   { LINE6_DEVICE(LINE6_DEVID_PODXT),
-   .driver_info = LINE6_PODXT },
-   { LINE6_DEVICE(LINE6_DEVID_PODXTLIVE),
-   .driver_info = LINE6_PODXTLIVE },
-   { LINE6_DEVICE(LINE6_DEVID_PODXTPRO),
-   .driver_info = LINE6_PODXTPRO },
-   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_GX),
-   .driver_info = LINE6_TONEPORT_GX },
-   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_UX1),
-   .driver_info = LINE6_TONEPORT_UX1 },
-   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_UX2),
-   .driver_info = LINE6_TONEPORT_UX2 },
-   { LINE6_DEVICE(LINE6_DEVID_VARIAX),
-   .driver_info = LINE6_VARIAX },
+   { LINE6_DEVICE(0x4250),.driver_info = LINE6_BASSPODXT },
+   { LINE6_DEVICE(0x4642),.driver_info = LINE6_BASSPODXTLIVE },
+   { LINE6_DEVICE(0x4252),.driver_info = LINE6_BASSPODXTPRO },
+   { LINE6_DEVICE(0x4750),.driver_info = LINE6_GUITARPORT },
+   { LINE6_DEVICE(0x5051),.driver_info = LINE6_POCKETPOD },
+   { LINE6_DEVICE(0x5057),.driver_info = LINE6_PODHD300 },
+   { LINE6_DEVICE(0x5058),.driver_info = LINE6_PODHD400 },
+   { LINE6_DEVICE(0x414D),.driver_info = LINE6_PODHD500 },
+   { LINE6_DEVICE(0x4153),.driver_info = LINE6_PODSTUDIO_GX },
+   { LINE6_DEVICE(0x4150),.driver_info = LINE6_PODSTUDIO_UX1 },
+   { LINE6_DEVICE(0x4151),.driver_info = LINE6_PODSTUDIO_UX2 },
+   { LINE6_DEVICE(0x5044),.driver_info = LINE6_PODXT },
+   { LINE6_DEVICE(0x4650),.driver_info = LINE6_PODXTLIVE },
+   { LINE6_DEVICE(0x5050),.driver_info = LINE6_PODXTPRO },
+   { LINE6_DEVICE(0x4147),.driver_info = LINE6_TONEPORT_GX },
+   { LINE6_DEVICE(0x4141),.driver_info = LINE6_TONEPORT_UX1 },
+   { LINE6_DEVICE(0x4142),.driver_info = LINE6_TONEPORT_UX2 },
+   { LINE6_DEVICE(0x534d),.driver_info = LINE6_VARIAX },
{}
 };
 
diff --git a/drivers/staging/line6/usbdefs.h b/drivers/staging/line6/usbdefs.h
index 06bf909..c897dba 100644
--- a/drivers/staging/line6/usbdefs.h
+++ b/drivers/staging/line6/usbdefs.h
@@ -12,32 +12,8 @@
 #ifndef USBDEFS_H
 #define USBDEFS_H
 
-#define LINE6_VENDOR_ID  0x0e41
-
 #define USB_INTERVALS_PER_SECOND 1000
 
-/*
-   Device ids.
-*/
-#define LINE6_DEVID_BASSPODXT 0x4250
-#define LINE6_DEVID_BASSPODXTLIVE 0x4642
-#define LINE6_DEVID_BASSPODXTPRO  0x4252
-#define LINE6_DEVID_GUITARPORT0x4750
-#define LINE6_DEVID_POCKETPOD 0x5051
-#define LINE6_DEVID_PODHD300  0x5057
-#define LINE6_DEVID_PODHD400  0x5058
-#define LINE6_DEVID_PODHD500  0x414D
-#define LINE6_DEVID_PODSTUDIO_GX  0x4153
-#define LINE6_DEVID_PODSTUDIO_UX1 0x4150
-#define LINE6_DEVID_PODSTUDIO_UX2 0x4151
-#define LINE6_DEVID_PODXT 0x5044
-#define LINE6_DEVID_PODXTLIVE 0x4650
-#define LINE6_DEVID_PODXTPRO  0x5050
-#define LINE6_DEVID_TONEPORT_GX   0x4147
-#define LINE6_DEVID_TONEPORT_UX1  

[PATCH 09/25] staging: line6: Remove useless comments

2015-01-09 Thread Chris Rorvick
Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 6dc8a0d..acde205 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -61,7 +61,6 @@ MODULE_DEVICE_TABLE(usb, line6_id_table);
{.id = dev_id,\
 .name = dev_name, .capabilities = LINE6_BIT_##dev_cap}
 
-/* *INDENT-OFF* */
 static const struct line6_properties line6_properties_table[] = {
L6PROP("BassPODxt", "BassPODxt",CTRL_PCM_HW),
L6PROP("BassPODxtLive", "BassPODxt Live",   CTRL_PCM_HW),
@@ -82,7 +81,6 @@ static const struct line6_properties line6_properties_table[] 
= {
L6PROP("TonePortUX2",   "TonePort UX2", PCM),
L6PROP("Variax","Variax Workbench", CONTROL),
 };
-/* *INDENT-ON* */
 
 /*
This is Line6's MIDI manufacturer ID.
-- 
2.1.0

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


[PATCH 10/25] staging: line6: Rename capability macros

2015-01-09 Thread Chris Rorvick
Including "BIT" in the macro name is pointless.  Replace with "CAP" to
provide some context for what its value represents.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c   |  8 
 drivers/staging/line6/midi.c |  2 +-
 drivers/staging/line6/pcm.c  |  2 +-
 drivers/staging/line6/playback.c |  2 +-
 drivers/staging/line6/pod.c  |  2 +-
 drivers/staging/line6/usbdefs.h  | 12 ++--
 6 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index acde205..4ec87a3 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -59,7 +59,7 @@ MODULE_DEVICE_TABLE(usb, line6_id_table);
 
 #define L6PROP(dev_id, dev_name, dev_cap)\
{.id = dev_id,\
-.name = dev_name, .capabilities = LINE6_BIT_##dev_cap}
+.name = dev_name, .capabilities = LINE6_CAP_##dev_cap}
 
 static const struct line6_properties line6_properties_table[] = {
L6PROP("BassPODxt", "BassPODxt",CTRL_PCM_HW),
@@ -830,7 +830,7 @@ static int line6_probe(struct usb_interface *interface,
 
usb_set_intfdata(interface, line6);
 
-   if (properties->capabilities & LINE6_BIT_CONTROL) {
+   if (properties->capabilities & LINE6_CAP_CONTROL) {
/* initialize USB buffers: */
line6->buffer_listen =
kmalloc(LINE6_BUFSIZE_LISTEN, GFP_KERNEL);
@@ -1052,7 +1052,7 @@ static int line6_suspend(struct usb_interface *interface, 
pm_message_t message)
 
snd_power_change_state(line6->card, SNDRV_CTL_POWER_D3hot);
 
-   if (line6->properties->capabilities & LINE6_BIT_CONTROL)
+   if (line6->properties->capabilities & LINE6_CAP_CONTROL)
line6_stop_listen(line6);
 
if (line6pcm != NULL) {
@@ -1071,7 +1071,7 @@ static int line6_resume(struct usb_interface *interface)
 {
struct usb_line6 *line6 = usb_get_intfdata(interface);
 
-   if (line6->properties->capabilities & LINE6_BIT_CONTROL)
+   if (line6->properties->capabilities & LINE6_CAP_CONTROL)
line6_start_listen(line6);
 
snd_power_change_state(line6->card, SNDRV_CTL_POWER_D0);
diff --git a/drivers/staging/line6/midi.c b/drivers/staging/line6/midi.c
index 1ac343b..c453485 100644
--- a/drivers/staging/line6/midi.c
+++ b/drivers/staging/line6/midi.c
@@ -279,7 +279,7 @@ int line6_init_midi(struct usb_line6 *line6)
int err;
struct snd_line6_midi *line6midi;
 
-   if (!(line6->properties->capabilities & LINE6_BIT_CONTROL)) {
+   if (!(line6->properties->capabilities & LINE6_CAP_CONTROL)) {
/* skip MIDI initialization and report success */
return 0;
}
diff --git a/drivers/staging/line6/pcm.c b/drivers/staging/line6/pcm.c
index 86c7bcb..e09772f 100644
--- a/drivers/staging/line6/pcm.c
+++ b/drivers/staging/line6/pcm.c
@@ -424,7 +424,7 @@ int line6_init_pcm(struct usb_line6 *line6,
int ep_read = 0, ep_write = 0;
struct snd_line6_pcm *line6pcm;
 
-   if (!(line6->properties->capabilities & LINE6_BIT_PCM))
+   if (!(line6->properties->capabilities & LINE6_CAP_PCM))
return 0;   /* skip PCM initialization and report success */
 
/* initialize PCM subsystem based on device: */
diff --git a/drivers/staging/line6/playback.c b/drivers/staging/line6/playback.c
index 2ca8900..54b7f60 100644
--- a/drivers/staging/line6/playback.c
+++ b/drivers/staging/line6/playback.c
@@ -261,7 +261,7 @@ static int submit_audio_out_urb(struct snd_line6_pcm 
*line6pcm)
 #endif
if (!
(line6pcm->line6->
-properties->capabilities & LINE6_BIT_HWMON)
+properties->capabilities & LINE6_CAP_HWMON)
&& (line6pcm->flags & LINE6_BITS_PLAYBACK_STREAM)
&& (line6pcm->flags & LINE6_BITS_CAPTURE_STREAM))
add_monitor_signal(urb_out, line6pcm->prev_fbuf,
diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index 7b4ec92f..0fb1788 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -396,7 +396,7 @@ static int pod_try_init(struct usb_interface *interface,
   handler.
 */
 
-   if (pod->line6.properties->capabilities & LINE6_BIT_CONTROL) {
+   if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL) {
pod->monitor_level = POD_SYSTEM_INVALID;
 
/* initiate startup procedure: */
diff --git a/drivers/staging/line6/usbdefs.h b/drivers/staging/line6/usbdefs.h
index c897dba..d6e46ee 100644
--- a/drivers/staging/line6/usbdefs.h
+++ b/drivers/staging/line6/usbdefs.h
@@ -15,15 +15,15 @@
 #define USB_INTERVALS_PER_SECOND 1000
 
 /* device supports settings parameter via USB */
-#define LINE6_BIT_CONTROL (1 << 0)
+#define LINE6_CAP_CONTROL (1 << 0)
 /* device supports 

[PATCH 04/25] staging: line6: Cleanup device table

2015-01-09 Thread Chris Rorvick
Wrap USB_DEVICE to avoid repeating the Line 6 vendor ID.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index e40400b..a263bce 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -30,27 +30,29 @@
 #define DRIVER_DESC"Line6 USB Driver"
 #define DRIVER_VERSION "0.9.1beta" DRIVER_REVISION
 
+#define LINE6_DEVICE(prod) USB_DEVICE(LINE6_VENDOR_ID, prod)
+
 /* table of devices that work with this driver */
 static const struct usb_device_id line6_id_table[] = {
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_BASSPODXT)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_BASSPODXTLIVE)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_BASSPODXTPRO)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_GUITARPORT)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_POCKETPOD)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD300)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD400)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD500)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_GX)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_UX1)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_UX2)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODXT)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODXTLIVE)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODXTPRO)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_TONEPORT_GX)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_TONEPORT_UX1)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_TONEPORT_UX2)},
-   {USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_VARIAX)},
-   {},
+   { LINE6_DEVICE(LINE6_DEVID_BASSPODXT) },
+   { LINE6_DEVICE(LINE6_DEVID_BASSPODXTLIVE) },
+   { LINE6_DEVICE(LINE6_DEVID_BASSPODXTPRO) },
+   { LINE6_DEVICE(LINE6_DEVID_GUITARPORT) },
+   { LINE6_DEVICE(LINE6_DEVID_POCKETPOD) },
+   { LINE6_DEVICE(LINE6_DEVID_PODHD300) },
+   { LINE6_DEVICE(LINE6_DEVID_PODHD400) },
+   { LINE6_DEVICE(LINE6_DEVID_PODHD500) },
+   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_GX) },
+   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_UX1) },
+   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_UX2) },
+   { LINE6_DEVICE(LINE6_DEVID_PODXT) },
+   { LINE6_DEVICE(LINE6_DEVID_PODXTLIVE) },
+   { LINE6_DEVICE(LINE6_DEVID_PODXTPRO) },
+   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_GX) },
+   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_UX1) },
+   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_UX2) },
+   { LINE6_DEVICE(LINE6_DEVID_VARIAX) },
+   {}
 };
 
 MODULE_DEVICE_TABLE(usb, line6_id_table);
-- 
2.1.0

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


[PATCH 05/25] staging: line6: Define a device type enum

2015-01-09 Thread Chris Rorvick
Define an enum containing the supported devices and associate each entry
in the device table to the respective value.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 54 --
 drivers/staging/line6/driver.h | 21 
 2 files changed, 57 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index a263bce..2797e41 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -34,24 +34,42 @@
 
 /* table of devices that work with this driver */
 static const struct usb_device_id line6_id_table[] = {
-   { LINE6_DEVICE(LINE6_DEVID_BASSPODXT) },
-   { LINE6_DEVICE(LINE6_DEVID_BASSPODXTLIVE) },
-   { LINE6_DEVICE(LINE6_DEVID_BASSPODXTPRO) },
-   { LINE6_DEVICE(LINE6_DEVID_GUITARPORT) },
-   { LINE6_DEVICE(LINE6_DEVID_POCKETPOD) },
-   { LINE6_DEVICE(LINE6_DEVID_PODHD300) },
-   { LINE6_DEVICE(LINE6_DEVID_PODHD400) },
-   { LINE6_DEVICE(LINE6_DEVID_PODHD500) },
-   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_GX) },
-   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_UX1) },
-   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_UX2) },
-   { LINE6_DEVICE(LINE6_DEVID_PODXT) },
-   { LINE6_DEVICE(LINE6_DEVID_PODXTLIVE) },
-   { LINE6_DEVICE(LINE6_DEVID_PODXTPRO) },
-   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_GX) },
-   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_UX1) },
-   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_UX2) },
-   { LINE6_DEVICE(LINE6_DEVID_VARIAX) },
+   { LINE6_DEVICE(LINE6_DEVID_BASSPODXT),
+   .driver_info = LINE6_BASSPODXT },
+   { LINE6_DEVICE(LINE6_DEVID_BASSPODXTLIVE),
+   .driver_info = LINE6_BASSPODXTLIVE },
+   { LINE6_DEVICE(LINE6_DEVID_BASSPODXTPRO),
+   .driver_info = LINE6_BASSPODXTPRO },
+   { LINE6_DEVICE(LINE6_DEVID_GUITARPORT),
+   .driver_info = LINE6_GUITARPORT },
+   { LINE6_DEVICE(LINE6_DEVID_POCKETPOD),
+   .driver_info = LINE6_POCKETPOD },
+   { LINE6_DEVICE(LINE6_DEVID_PODHD300),
+   .driver_info = LINE6_PODHD300 },
+   { LINE6_DEVICE(LINE6_DEVID_PODHD400),
+   .driver_info = LINE6_PODHD400 },
+   { LINE6_DEVICE(LINE6_DEVID_PODHD500),
+   .driver_info = LINE6_PODHD500 },
+   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_GX),
+   .driver_info = LINE6_PODSTUDIO_GX },
+   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_UX1),
+   .driver_info = LINE6_PODSTUDIO_UX1 },
+   { LINE6_DEVICE(LINE6_DEVID_PODSTUDIO_UX2),
+   .driver_info = LINE6_PODSTUDIO_UX2 },
+   { LINE6_DEVICE(LINE6_DEVID_PODXT),
+   .driver_info = LINE6_PODXT },
+   { LINE6_DEVICE(LINE6_DEVID_PODXTLIVE),
+   .driver_info = LINE6_PODXTLIVE },
+   { LINE6_DEVICE(LINE6_DEVID_PODXTPRO),
+   .driver_info = LINE6_PODXTPRO },
+   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_GX),
+   .driver_info = LINE6_TONEPORT_GX },
+   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_UX1),
+   .driver_info = LINE6_TONEPORT_UX1 },
+   { LINE6_DEVICE(LINE6_DEVID_TONEPORT_UX2),
+   .driver_info = LINE6_TONEPORT_UX2 },
+   { LINE6_DEVICE(LINE6_DEVID_VARIAX),
+   .driver_info = LINE6_VARIAX },
{}
 };
 
diff --git a/drivers/staging/line6/driver.h b/drivers/staging/line6/driver.h
index 1cc7532..8fb4a9c 100644
--- a/drivers/staging/line6/driver.h
+++ b/drivers/staging/line6/driver.h
@@ -20,6 +20,27 @@
 
 #define DRIVER_NAME "line6usb"
 
+enum line6_device_type {
+   LINE6_BASSPODXT,
+   LINE6_BASSPODXTLIVE,
+   LINE6_BASSPODXTPRO,
+   LINE6_GUITARPORT,
+   LINE6_POCKETPOD,
+   LINE6_PODHD300,
+   LINE6_PODHD400,
+   LINE6_PODHD500,
+   LINE6_PODSTUDIO_GX,
+   LINE6_PODSTUDIO_UX1,
+   LINE6_PODSTUDIO_UX2,
+   LINE6_PODXT,
+   LINE6_PODXTLIVE,
+   LINE6_PODXTPRO,
+   LINE6_TONEPORT_GX,
+   LINE6_TONEPORT_UX1,
+   LINE6_TONEPORT_UX2,
+   LINE6_VARIAX
+};
+
 #define LINE6_TIMEOUT 1
 #define LINE6_BUFSIZE_LISTEN 32
 #define LINE6_MESSAGE_MAXLEN 256
-- 
2.1.0

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


[PATCH 12/25] staging: line6: List out capabilities individually

2015-01-09 Thread Chris Rorvick
The `LINE6_CAP_CTRL_PCM_HW' macro combines three capabilities to save
horizontal space when defining the properties entries.  Now that these
are no longer limited to single lines this is not such a concern.
Specify capabilities individually when defining each property for
better clarity.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c  | 54 +++--
 drivers/staging/line6/usbdefs.h |  4 ---
 2 files changed, 36 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index c988b78..6fecc1b 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -61,92 +61,110 @@ static const struct line6_properties 
line6_properties_table[] = {
[LINE6_BASSPODXT] = {
.id = "BassPODxt",
.name = "BassPODxt",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_BASSPODXTLIVE] = {
.id = "BassPODxtLive",
.name = "BassPODxt Live",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_BASSPODXTPRO] = {
.id = "BassPODxtPro",
.name = "BassPODxt Pro",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_GUITARPORT] = {
.id = "GuitarPort",
.name = "GuitarPort",
-   .capabilities = LINE6_CAP_PCM,
+   .capabilities   = LINE6_CAP_PCM,
},
[LINE6_POCKETPOD] = {
.id = "PocketPOD",
.name = "Pocket POD",
-   .capabilities = LINE6_CAP_CONTROL,
+   .capabilities   = LINE6_CAP_CONTROL,
},
[LINE6_PODHD300] = {
.id = "PODHD300",
.name = "POD HD300",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_PODHD400] = {
.id = "PODHD400",
.name = "POD HD400",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_PODHD500] = {
.id = "PODHD500",
.name = "POD HD500",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_PODSTUDIO_GX] = {
.id = "PODStudioGX",
.name = "POD Studio GX",
-   .capabilities = LINE6_CAP_PCM,
+   .capabilities   = LINE6_CAP_PCM,
},
[LINE6_PODSTUDIO_UX1] = {
.id = "PODStudioUX1",
.name = "POD Studio UX1",
-   .capabilities = LINE6_CAP_PCM,
+   .capabilities   = LINE6_CAP_PCM,
},
[LINE6_PODSTUDIO_UX2] = {
.id = "PODStudioUX2",
.name = "POD Studio UX2",
-   .capabilities = LINE6_CAP_PCM,
+   .capabilities   = LINE6_CAP_PCM,
},
[LINE6_PODXT] = {
.id = "PODxt",
.name = "PODxt",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_PODXTLIVE] = {
.id = "PODxtLive",
.name = "PODxt Live",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_PODXTPRO] = {
.id = "PODxtPro",
.name = "PODxt Pro",
-   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
},
[LINE6_TONEPORT_GX] = {
.id = "TonePortGX",
.name = "TonePort GX",
-   .capabilities = LINE6_CAP_PCM,
+   .capabilities   = LINE6_CAP_PCM,
},
[LINE6_TONEPORT_UX1] = {

[PATCH 11/25] staging: line6: Use explicit indexes when defining properties

2015-01-09 Thread Chris Rorvick
Specify the index of the properties entry explicitly to define this
structure more robustly.  Also, drop the `L6PROP' macro in favor of
initializing each member explicitly on its own line since horizontal
space is limited and more attributes will be added later.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 112 +
 1 file changed, 90 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 4ec87a3..c988b78 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -57,29 +57,97 @@ static const struct usb_device_id line6_id_table[] = {
 
 MODULE_DEVICE_TABLE(usb, line6_id_table);
 
-#define L6PROP(dev_id, dev_name, dev_cap)\
-   {.id = dev_id,\
-.name = dev_name, .capabilities = LINE6_CAP_##dev_cap}
-
 static const struct line6_properties line6_properties_table[] = {
-   L6PROP("BassPODxt", "BassPODxt",CTRL_PCM_HW),
-   L6PROP("BassPODxtLive", "BassPODxt Live",   CTRL_PCM_HW),
-   L6PROP("BassPODxtPro",  "BassPODxt Pro",CTRL_PCM_HW),
-   L6PROP("GuitarPort","GuitarPort",   PCM),
-   L6PROP("PocketPOD", "Pocket POD",   CONTROL),
-   L6PROP("PODHD300",  "POD HD300",CTRL_PCM_HW),
-   L6PROP("PODHD400",  "POD HD400",CTRL_PCM_HW),
-   L6PROP("PODHD500",  "POD HD500",CTRL_PCM_HW),
-   L6PROP("PODStudioGX",   "POD Studio GX",PCM),
-   L6PROP("PODStudioUX1",  "POD Studio UX1",   PCM),
-   L6PROP("PODStudioUX2",  "POD Studio UX2",   PCM),
-   L6PROP("PODxt", "PODxt",CTRL_PCM_HW),
-   L6PROP("PODxtLive", "PODxt Live",   CTRL_PCM_HW),
-   L6PROP("PODxtPro",  "PODxt Pro",CTRL_PCM_HW),
-   L6PROP("TonePortGX","TonePort GX",  PCM),
-   L6PROP("TonePortUX1",   "TonePort UX1", PCM),
-   L6PROP("TonePortUX2",   "TonePort UX2", PCM),
-   L6PROP("Variax","Variax Workbench", CONTROL),
+   [LINE6_BASSPODXT] = {
+   .id = "BassPODxt",
+   .name = "BassPODxt",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_BASSPODXTLIVE] = {
+   .id = "BassPODxtLive",
+   .name = "BassPODxt Live",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_BASSPODXTPRO] = {
+   .id = "BassPODxtPro",
+   .name = "BassPODxt Pro",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_GUITARPORT] = {
+   .id = "GuitarPort",
+   .name = "GuitarPort",
+   .capabilities = LINE6_CAP_PCM,
+   },
+   [LINE6_POCKETPOD] = {
+   .id = "PocketPOD",
+   .name = "Pocket POD",
+   .capabilities = LINE6_CAP_CONTROL,
+   },
+   [LINE6_PODHD300] = {
+   .id = "PODHD300",
+   .name = "POD HD300",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_PODHD400] = {
+   .id = "PODHD400",
+   .name = "POD HD400",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_PODHD500] = {
+   .id = "PODHD500",
+   .name = "POD HD500",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_PODSTUDIO_GX] = {
+   .id = "PODStudioGX",
+   .name = "POD Studio GX",
+   .capabilities = LINE6_CAP_PCM,
+   },
+   [LINE6_PODSTUDIO_UX1] = {
+   .id = "PODStudioUX1",
+   .name = "POD Studio UX1",
+   .capabilities = LINE6_CAP_PCM,
+   },
+   [LINE6_PODSTUDIO_UX2] = {
+   .id = "PODStudioUX2",
+   .name = "POD Studio UX2",
+   .capabilities = LINE6_CAP_PCM,
+   },
+   [LINE6_PODXT] = {
+   .id = "PODxt",
+   .name = "PODxt",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_PODXTLIVE] = {
+   .id = "PODxtLive",
+   .name = "PODxt Live",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_PODXTPRO] = {
+   .id = "PODxtPro",
+   .name = "PODxt Pro",
+   .capabilities = LINE6_CAP_CTRL_PCM_HW,
+   },
+   [LINE6_TONEPORT_GX] = {
+   .id = "TonePortGX",
+   .name = "TonePort GX",
+   .capabilities = LINE6_CAP_PCM,
+   },
+   [LINE6_TONEPORT_UX1] = {
+   .id = "TonePortUX1",
+   .name = "TonePort UX1",
+   .capabilities = LINE6_CAP_PCM,
+   },
+   [LINE6_TONEPORT_UX2] = {
+   .id = "TonePortUX2",
+   .name = "TonePort UX2",
+   .capabilities = LINE6_CAP_PCM,
+   },
+   [LINE6_VARIAX] = {
+   .id = "Variax",
+   .name = 

[PATCH 16/25] staging: line6: Filter on UX2 interfaces

2015-01-09 Thread Chris Rorvick
The driver only supports interface 0 of the TonePort UX2 and POD Studio
UX2 devices.  Use the device table to filter on this.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 8b03bc0..f04ff80 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -46,14 +46,14 @@ static const struct usb_device_id line6_id_table[] = {
{ LINE6_IF_NUM(0x414D, 1), .driver_info = LINE6_PODHD500_1 },
{ LINE6_DEVICE(0x4153),.driver_info = LINE6_PODSTUDIO_GX },
{ LINE6_DEVICE(0x4150),.driver_info = LINE6_PODSTUDIO_UX1 },
-   { LINE6_DEVICE(0x4151),.driver_info = LINE6_PODSTUDIO_UX2 },
+   { LINE6_IF_NUM(0x4151, 0), .driver_info = LINE6_PODSTUDIO_UX2 },
{ LINE6_DEVICE(0x5044),.driver_info = LINE6_PODXT },
{ LINE6_IF_NUM(0x4650, 0), .driver_info = LINE6_PODXTLIVE_POD },
{ LINE6_IF_NUM(0x4650, 1), .driver_info = LINE6_PODXTLIVE_VARIAX },
{ LINE6_DEVICE(0x5050),.driver_info = LINE6_PODXTPRO },
{ LINE6_DEVICE(0x4147),.driver_info = LINE6_TONEPORT_GX },
{ LINE6_DEVICE(0x4141),.driver_info = LINE6_TONEPORT_UX1 },
-   { LINE6_DEVICE(0x4142),.driver_info = LINE6_TONEPORT_UX2 },
+   { LINE6_IF_NUM(0x4142, 0), .driver_info = LINE6_TONEPORT_UX2 },
{ LINE6_DEVICE(0x534d),.driver_info = LINE6_VARIAX },
{}
 };
@@ -768,20 +768,8 @@ static int line6_probe(struct usb_interface *interface,
 
case LINE6_TONEPORT_UX2:
case LINE6_PODSTUDIO_UX2:
-   switch (interface_number) {
-   case 0:
-   /* defaults to 44.1kHz, 16-bit */
-   alternate = 2;
-   break;
-   case 1:
-   /* don't know yet what this is ...
-  alternate = 1;
-  break;
-*/
-   return -ENODEV;
-   default:
-   MISSING_CASE;
-   }
+   /* defaults to 44.1kHz, 16-bit */
+   alternate = 2;
break;
 
default:
-- 
2.1.0

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


[PATCH 14/25] staging: line6: Split out POD HD500 interfaces

2015-01-09 Thread Chris Rorvick
The driver uses a different altsetting depending on the interface.  Add
device type entries for each of these.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 41 -
 drivers/staging/line6/driver.h |  3 ++-
 drivers/staging/line6/pcm.c|  3 ++-
 3 files changed, 28 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index cb96029..e97e2cb 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -42,7 +42,8 @@ static const struct usb_device_id line6_id_table[] = {
{ LINE6_DEVICE(0x5051),.driver_info = LINE6_POCKETPOD },
{ LINE6_DEVICE(0x5057),.driver_info = LINE6_PODHD300 },
{ LINE6_DEVICE(0x5058),.driver_info = LINE6_PODHD400 },
-   { LINE6_DEVICE(0x414D),.driver_info = LINE6_PODHD500 },
+   { LINE6_IF_NUM(0x414D, 0), .driver_info = LINE6_PODHD500_0 },
+   { LINE6_IF_NUM(0x414D, 1), .driver_info = LINE6_PODHD500_1 },
{ LINE6_DEVICE(0x4153),.driver_info = LINE6_PODSTUDIO_GX },
{ LINE6_DEVICE(0x4150),.driver_info = LINE6_PODSTUDIO_UX1 },
{ LINE6_DEVICE(0x4151),.driver_info = LINE6_PODSTUDIO_UX2 },
@@ -105,7 +106,14 @@ static const struct line6_properties 
line6_properties_table[] = {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
},
-   [LINE6_PODHD500] = {
+   [LINE6_PODHD500_0] = {
+   .id = "PODHD500",
+   .name = "POD HD500",
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
+   },
+   [LINE6_PODHD500_1] = {
.id = "PODHD500",
.name = "POD HD500",
.capabilities   = LINE6_CAP_CONTROL
@@ -451,7 +459,8 @@ static void line6_data_received(struct urb *urb)
 
case LINE6_PODHD300:
case LINE6_PODHD400:
-   case LINE6_PODHD500:
+   case LINE6_PODHD500_0:
+   case LINE6_PODHD500_1:
break; /* let userspace handle MIDI */
 
case LINE6_PODXTLIVE_POD:
@@ -740,17 +749,12 @@ static int line6_probe(struct usb_interface *interface,
}
break;
 
-   case LINE6_PODHD500:
-   switch (interface_number) {
-   case 0:
-   alternate = 1;
-   break;
-   case 1:
-   alternate = 0;
-   break;
-   default:
-   MISSING_CASE;
-   }
+   case LINE6_PODHD500_0:
+   alternate = 1;
+   break;
+
+   case LINE6_PODHD500_1:
+   alternate = 0;
break;
 
case LINE6_BASSPODXT:
@@ -819,7 +823,8 @@ static int line6_probe(struct usb_interface *interface,
ep_write = 0x03;
break;
 
-   case LINE6_PODHD500:
+   case LINE6_PODHD500_0:
+   case LINE6_PODHD500_1:
size = sizeof(struct usb_line6_podhd);
ep_read = 0x81;
ep_write = 0x01;
@@ -954,7 +959,8 @@ static int line6_probe(struct usb_interface *interface,
 
case LINE6_PODHD300:
case LINE6_PODHD400:
-   case LINE6_PODHD500:
+   case LINE6_PODHD500_0:
+   case LINE6_PODHD500_1:
ret = line6_podhd_init(interface,
   (struct usb_line6_podhd *)line6);
break;
@@ -1061,7 +1067,8 @@ static void line6_disconnect(struct usb_interface 
*interface)
 
case LINE6_PODHD300:
case LINE6_PODHD400:
-   case LINE6_PODHD500:
+   case LINE6_PODHD500_0:
+   case LINE6_PODHD500_1:
line6_podhd_disconnect(interface);
break;
 
diff --git a/drivers/staging/line6/driver.h b/drivers/staging/line6/driver.h
index 085aa44..9d6b351 100644
--- a/drivers/staging/line6/driver.h
+++ b/drivers/staging/line6/driver.h
@@ -28,7 +28,8 @@ enum line6_device_type {
LINE6_POCKETPOD,
LINE6_PODHD300,
LINE6_PODHD400,
-   LINE6_PODHD500,
+   LINE6_PODHD500_0,
+   LINE6_PODHD500_1,
LINE6_PODSTUDIO_GX,
LINE6_PODSTUDIO_UX1,
LINE6_PODSTUDIO_UX2,
diff --git a/drivers/staging/line6/pcm.c b/drivers/staging/line6/pcm.c
index d09d1ea..d8450af 100644
--- a/drivers/staging/line6/pcm.c
+++ b/drivers/staging/line6/pcm.c
@@ -442,7 +442,8 @@ int line6_init_pcm(struct usb_line6 *line6,
ep_write = 0x01;
break;
 
-   case LINE6_PODHD500:
+   case LINE6_PODHD500_0:
+   case LINE6_PODHD500_1:
ep_read = 0x86;
ep_write = 0x02;
break;
-- 
2.1.0

--
To unsubscribe from this list: send the line 

[PATCH 13/25] staging: line6: Split out PODxt Live interfaces

2015-01-09 Thread Chris Rorvick
The PODxt Live device has both a POD and a Variax interface.  Add device
type entries for each of these.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 112 -
 drivers/staging/line6/driver.h |   8 +--
 drivers/staging/line6/pcm.c|   3 +-
 drivers/staging/line6/pod.h|   6 ---
 4 files changed, 48 insertions(+), 81 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 6fecc1b..cb96029 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -31,6 +31,7 @@
 #define DRIVER_VERSION "0.9.1beta" DRIVER_REVISION
 
 #define LINE6_DEVICE(prod) USB_DEVICE(0x0e41, prod)
+#define LINE6_IF_NUM(prod, n) USB_DEVICE_INTERFACE_NUMBER(0x0e41, prod, n)
 
 /* table of devices that work with this driver */
 static const struct usb_device_id line6_id_table[] = {
@@ -46,7 +47,8 @@ static const struct usb_device_id line6_id_table[] = {
{ LINE6_DEVICE(0x4150),.driver_info = LINE6_PODSTUDIO_UX1 },
{ LINE6_DEVICE(0x4151),.driver_info = LINE6_PODSTUDIO_UX2 },
{ LINE6_DEVICE(0x5044),.driver_info = LINE6_PODXT },
-   { LINE6_DEVICE(0x4650),.driver_info = LINE6_PODXTLIVE },
+   { LINE6_IF_NUM(0x4650, 0), .driver_info = LINE6_PODXTLIVE_POD },
+   { LINE6_IF_NUM(0x4650, 1), .driver_info = LINE6_PODXTLIVE_VARIAX },
{ LINE6_DEVICE(0x5050),.driver_info = LINE6_PODXTPRO },
{ LINE6_DEVICE(0x4147),.driver_info = LINE6_TONEPORT_GX },
{ LINE6_DEVICE(0x4141),.driver_info = LINE6_TONEPORT_UX1 },
@@ -132,7 +134,14 @@ static const struct line6_properties 
line6_properties_table[] = {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
},
-   [LINE6_PODXTLIVE] = {
+   [LINE6_PODXTLIVE_POD] = {
+   .id = "PODxtLive",
+   .name = "PODxt Live",
+   .capabilities   = LINE6_CAP_CONTROL
+   | LINE6_CAP_PCM
+   | LINE6_CAP_HWMON,
+   },
+   [LINE6_PODXTLIVE_VARIAX] = {
.id = "PODxtLive",
.name = "PODxt Live",
.capabilities   = LINE6_CAP_CONTROL
@@ -445,24 +454,15 @@ static void line6_data_received(struct urb *urb)
case LINE6_PODHD500:
break; /* let userspace handle MIDI */
 
-   case LINE6_PODXTLIVE:
-   switch (line6->interface_number) {
-   case PODXTLIVE_INTERFACE_POD:
-   line6_pod_process_message((struct usb_line6_pod
+   case LINE6_PODXTLIVE_POD:
+   line6_pod_process_message((struct usb_line6_pod
   *)line6);
-   break;
-
-   case PODXTLIVE_INTERFACE_VARIAX:
-   line6_variax_process_message((struct
- usb_line6_variax
- *)line6);
-   break;
-
-   default:
-   dev_err(line6->ifcdev,
-   "PODxt Live interface %d not 
supported\n",
-   line6->interface_number);
-   }
+   break;
+
+   case LINE6_PODXTLIVE_VARIAX:
+   line6_variax_process_message((struct
+ usb_line6_variax
+ *)line6);
break;
 
case LINE6_VARIAX:
@@ -722,7 +722,8 @@ static int line6_probe(struct usb_interface *interface,
 
switch (devtype) {
case LINE6_BASSPODXTLIVE:
-   case LINE6_PODXTLIVE:
+   case LINE6_PODXTLIVE_POD:
+   case LINE6_PODXTLIVE_VARIAX:
case LINE6_VARIAX:
alternate = 1;
break;
@@ -841,24 +842,16 @@ static int line6_probe(struct usb_interface *interface,
/* these don't have a control channel */
break;
 
-   case LINE6_PODXTLIVE:
-   switch (interface_number) {
-   case PODXTLIVE_INTERFACE_POD:
-   size = sizeof(struct usb_line6_pod);
-   ep_read = 0x84;
-   ep_write = 0x03;
-   break;
-
-   case PODXTLIVE_INTERFACE_VARIAX:
-   size = sizeof(struct usb_line6_variax);
-   ep_read = 0x86;
-   ep_write = 0x05;
-   break;
+   case LINE6_PODXTLIVE_POD:
+   size = sizeof(struct usb_line6_pod);
+   ep_read = 0x84;
+   ep_write = 0x03;
+   break;
 
-   

[PATCH 20/25] staging: line6: Move audio endpoints to properties

2015-01-09 Thread Chris Rorvick
The device type can now be used to determine the addresses of the
audio endpoints for the interface.  Drop the conditional logic and make
these values properties.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/capture.c  |  9 
 drivers/staging/line6/driver.c   | 38 +++
 drivers/staging/line6/driver.h   |  2 ++
 drivers/staging/line6/pcm.c  | 48 ++--
 drivers/staging/line6/pcm.h  | 10 -
 drivers/staging/line6/playback.c |  9 
 6 files changed, 52 insertions(+), 64 deletions(-)

diff --git a/drivers/staging/line6/capture.c b/drivers/staging/line6/capture.c
index e6ca631..f24c7c5 100644
--- a/drivers/staging/line6/capture.c
+++ b/drivers/staging/line6/capture.c
@@ -400,6 +400,7 @@ struct snd_pcm_ops snd_line6_capture_ops = {
 
 int line6_create_audio_in_urbs(struct snd_line6_pcm *line6pcm)
 {
+   struct usb_line6 *line6 = line6pcm->line6;
int i;
 
/* create audio URBs and fill in constant values: */
@@ -411,14 +412,14 @@ int line6_create_audio_in_urbs(struct snd_line6_pcm 
*line6pcm)
usb_alloc_urb(LINE6_ISO_PACKETS, GFP_KERNEL);
 
if (urb == NULL) {
-   dev_err(line6pcm->line6->ifcdev, "Out of memory\n");
+   dev_err(line6->ifcdev, "Out of memory\n");
return -ENOMEM;
}
 
-   urb->dev = line6pcm->line6->usbdev;
+   urb->dev = line6->usbdev;
urb->pipe =
-   usb_rcvisocpipe(line6pcm->line6->usbdev,
-   line6pcm->ep_audio_read &
+   usb_rcvisocpipe(line6->usbdev,
+   line6->properties->ep_audio_r &
USB_ENDPOINT_NUMBER_MASK);
urb->transfer_flags = URB_ISO_ASAP;
urb->start_frame = -1;
diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 40ec57c..4bfef21 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -70,6 +70,8 @@ static const struct line6_properties line6_properties_table[] 
= {
.altsetting = 5,
.ep_ctrl_r = 0x84,
.ep_ctrl_w = 0x03,
+   .ep_audio_r = 0x82,
+   .ep_audio_w = 0x01,
},
[LINE6_BASSPODXTLIVE] = {
.id = "BassPODxtLive",
@@ -80,6 +82,8 @@ static const struct line6_properties line6_properties_table[] 
= {
.altsetting = 1,
.ep_ctrl_r = 0x84,
.ep_ctrl_w = 0x03,
+   .ep_audio_r = 0x82,
+   .ep_audio_w = 0x01,
},
[LINE6_BASSPODXTPRO] = {
.id = "BassPODxtPro",
@@ -90,6 +94,8 @@ static const struct line6_properties line6_properties_table[] 
= {
.altsetting = 5,
.ep_ctrl_r = 0x84,
.ep_ctrl_w = 0x03,
+   .ep_audio_r = 0x82,
+   .ep_audio_w = 0x01,
},
[LINE6_GUITARPORT] = {
.id = "GuitarPort",
@@ -97,6 +103,8 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_PCM,
.altsetting = 2,  /* 1..4 seem to be ok */
/* no control channel */
+   .ep_audio_r = 0x82,
+   .ep_audio_w = 0x01,
},
[LINE6_POCKETPOD] = {
.id = "PocketPOD",
@@ -105,6 +113,7 @@ static const struct line6_properties 
line6_properties_table[] = {
.altsetting = 0,
.ep_ctrl_r = 0x82,
.ep_ctrl_w = 0x02,
+   /* no audio channel */
},
[LINE6_PODHD300] = {
.id = "PODHD300",
@@ -115,6 +124,8 @@ static const struct line6_properties 
line6_properties_table[] = {
.altsetting = 5,
.ep_ctrl_r = 0x84,
.ep_ctrl_w = 0x03,
+   .ep_audio_r = 0x82,
+   .ep_audio_w = 0x01,
},
[LINE6_PODHD400] = {
.id = "PODHD400",
@@ -125,6 +136,8 @@ static const struct line6_properties 
line6_properties_table[] = {
.altsetting = 5,
.ep_ctrl_r = 0x84,
.ep_ctrl_w = 0x03,
+   .ep_audio_r = 0x82,
+   .ep_audio_w = 0x01,
},
[LINE6_PODHD500_0] = {
.id = "PODHD500",
@@ -135,6 +148,8 @@ static const struct line6_properties 
line6_properties_table[] = {
.altsetting = 1,
.ep_ctrl_r = 0x81,
.ep_ctrl_w = 0x01,
+   .ep_audio_r = 0x86,
+   .ep_audio_w = 0x02,
},
[LINE6_PODHD500_1] = {
.id = "PODHD500",
@@ -145,6 +160,8 @@ static const struct line6_properties 
line6_properties_table[] = {
.altsetting = 1,
.ep_ctrl_r 

[PATCH 17/25] staging: line6: Move altsetting to properties

2015-01-09 Thread Chris Rorvick
The device type can now be used to determine the altsetting for the
interface.  Drop the conditional logic and make this value a property.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 74 +-
 drivers/staging/line6/driver.h |  2 ++
 2 files changed, 25 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index f04ff80..0150470 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -67,6 +67,7 @@ static const struct line6_properties line6_properties_table[] 
= {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 5,
},
[LINE6_BASSPODXTLIVE] = {
.id = "BassPODxtLive",
@@ -74,6 +75,7 @@ static const struct line6_properties line6_properties_table[] 
= {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 1,
},
[LINE6_BASSPODXTPRO] = {
.id = "BassPODxtPro",
@@ -81,16 +83,19 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 5,
},
[LINE6_GUITARPORT] = {
.id = "GuitarPort",
.name = "GuitarPort",
.capabilities   = LINE6_CAP_PCM,
+   .altsetting = 2,  /* 1..4 seem to be ok */
},
[LINE6_POCKETPOD] = {
.id = "PocketPOD",
.name = "Pocket POD",
.capabilities   = LINE6_CAP_CONTROL,
+   .altsetting = 0,
},
[LINE6_PODHD300] = {
.id = "PODHD300",
@@ -98,6 +103,7 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 5,
},
[LINE6_PODHD400] = {
.id = "PODHD400",
@@ -105,6 +111,7 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 5,
},
[LINE6_PODHD500_0] = {
.id = "PODHD500",
@@ -112,6 +119,7 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 1,
},
[LINE6_PODHD500_1] = {
.id = "PODHD500",
@@ -119,21 +127,25 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 1,
},
[LINE6_PODSTUDIO_GX] = {
.id = "PODStudioGX",
.name = "POD Studio GX",
.capabilities   = LINE6_CAP_PCM,
+   .altsetting = 2,  /* 1..4 seem to be ok */
},
[LINE6_PODSTUDIO_UX1] = {
.id = "PODStudioUX1",
.name = "POD Studio UX1",
.capabilities   = LINE6_CAP_PCM,
+   .altsetting = 2,  /* 1..4 seem to be ok */
},
[LINE6_PODSTUDIO_UX2] = {
.id = "PODStudioUX2",
.name = "POD Studio UX2",
.capabilities   = LINE6_CAP_PCM,
+   .altsetting = 2,  /* defaults to 44.1kHz, 16-bit */
},
[LINE6_PODXT] = {
.id = "PODxt",
@@ -141,6 +153,7 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 5,
},
[LINE6_PODXTLIVE_POD] = {
.id = "PODxtLive",
@@ -148,6 +161,7 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
+   .altsetting = 1,
},
[LINE6_PODXTLIVE_VARIAX] = {
.id = "PODxtLive",
@@ -155,6 +169,7 @@ static const struct line6_properties 
line6_properties_table[] = {
.capabilities   = LINE6_CAP_CONTROL
| LINE6_CAP_PCM
  

[PATCH 18/25] staging: line6: Move control endpoints to properties

2015-01-09 Thread Chris Rorvick
The device type can now be used to determine the addresses of the
control endpoints for the interface.  Drop the conditional logic and
make these values properties.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 73 +-
 drivers/staging/line6/driver.h | 13 ++--
 drivers/staging/line6/midi.c   |  2 +-
 3 files changed, 48 insertions(+), 40 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 0150470..40ec57c 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -68,6 +68,8 @@ static const struct line6_properties line6_properties_table[] 
= {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
.altsetting = 5,
+   .ep_ctrl_r = 0x84,
+   .ep_ctrl_w = 0x03,
},
[LINE6_BASSPODXTLIVE] = {
.id = "BassPODxtLive",
@@ -76,6 +78,8 @@ static const struct line6_properties line6_properties_table[] 
= {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
.altsetting = 1,
+   .ep_ctrl_r = 0x84,
+   .ep_ctrl_w = 0x03,
},
[LINE6_BASSPODXTPRO] = {
.id = "BassPODxtPro",
@@ -84,18 +88,23 @@ static const struct line6_properties 
line6_properties_table[] = {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
.altsetting = 5,
+   .ep_ctrl_r = 0x84,
+   .ep_ctrl_w = 0x03,
},
[LINE6_GUITARPORT] = {
.id = "GuitarPort",
.name = "GuitarPort",
.capabilities   = LINE6_CAP_PCM,
.altsetting = 2,  /* 1..4 seem to be ok */
+   /* no control channel */
},
[LINE6_POCKETPOD] = {
.id = "PocketPOD",
.name = "Pocket POD",
.capabilities   = LINE6_CAP_CONTROL,
.altsetting = 0,
+   .ep_ctrl_r = 0x82,
+   .ep_ctrl_w = 0x02,
},
[LINE6_PODHD300] = {
.id = "PODHD300",
@@ -104,6 +113,8 @@ static const struct line6_properties 
line6_properties_table[] = {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
.altsetting = 5,
+   .ep_ctrl_r = 0x84,
+   .ep_ctrl_w = 0x03,
},
[LINE6_PODHD400] = {
.id = "PODHD400",
@@ -112,6 +123,8 @@ static const struct line6_properties 
line6_properties_table[] = {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
.altsetting = 5,
+   .ep_ctrl_r = 0x84,
+   .ep_ctrl_w = 0x03,
},
[LINE6_PODHD500_0] = {
.id = "PODHD500",
@@ -120,6 +133,8 @@ static const struct line6_properties 
line6_properties_table[] = {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
.altsetting = 1,
+   .ep_ctrl_r = 0x81,
+   .ep_ctrl_w = 0x01,
},
[LINE6_PODHD500_1] = {
.id = "PODHD500",
@@ -128,24 +143,29 @@ static const struct line6_properties 
line6_properties_table[] = {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
.altsetting = 1,
+   .ep_ctrl_r = 0x81,
+   .ep_ctrl_w = 0x01,
},
[LINE6_PODSTUDIO_GX] = {
.id = "PODStudioGX",
.name = "POD Studio GX",
.capabilities   = LINE6_CAP_PCM,
.altsetting = 2,  /* 1..4 seem to be ok */
+   /* no control channel */
},
[LINE6_PODSTUDIO_UX1] = {
.id = "PODStudioUX1",
.name = "POD Studio UX1",
.capabilities   = LINE6_CAP_PCM,
.altsetting = 2,  /* 1..4 seem to be ok */
+   /* no control channel */
},
[LINE6_PODSTUDIO_UX2] = {
.id = "PODStudioUX2",
.name = "POD Studio UX2",
.capabilities   = LINE6_CAP_PCM,
.altsetting = 2,  /* defaults to 44.1kHz, 16-bit */
+   /* no control channel */
},
[LINE6_PODXT] = {
.id = "PODxt",
@@ -154,6 +174,8 @@ static const struct line6_properties 
line6_properties_table[] = {
| LINE6_CAP_PCM
| LINE6_CAP_HWMON,
.altsetting = 5,
+   .ep_ctrl_r = 0x84,
+   .ep_ctrl_w = 0x03,
},
[LINE6_PODXTLIVE_POD] = {
.id = "PODxtLive",
@@ -162,6 +184,8 @@ static const struct line6_properties 
line6_properties_table[] = {
 

[PATCH 19/25] staging: line6: Remove stale Pocket POD PCM endpoints

2015-01-09 Thread Chris Rorvick
Commit 1027f476f507 (staging: line6: sync with upstream) removed PCM
from the Pocket POD capabilities but left the endpoint configuration.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/pcm.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/line6/pcm.c b/drivers/staging/line6/pcm.c
index d8450af..19aa927 100644
--- a/drivers/staging/line6/pcm.c
+++ b/drivers/staging/line6/pcm.c
@@ -448,11 +448,6 @@ int line6_init_pcm(struct usb_line6 *line6,
ep_write = 0x02;
break;
 
-   case LINE6_POCKETPOD:
-   ep_read = 0x82;
-   ep_write = 0x02;
-   break;
-
case LINE6_GUITARPORT:
case LINE6_PODSTUDIO_GX:
case LINE6_PODSTUDIO_UX1:
-- 
2.1.0

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


[PATCH 21/25] staging: line6: Pass *_init() `usb_line6' pointers

2015-01-09 Thread Chris Rorvick
Casting the `struct usb_line6' pointer at the call point makes the code
difficult to read.  This is substantially cleaned up by moving the cast
into the callees.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c   | 21 ++---
 drivers/staging/line6/pod.c  |  8 
 drivers/staging/line6/pod.h  |  2 +-
 drivers/staging/line6/podhd.c|  4 ++--
 drivers/staging/line6/podhd.h|  2 +-
 drivers/staging/line6/toneport.c |  8 
 drivers/staging/line6/toneport.h |  2 +-
 drivers/staging/line6/variax.c   |  8 
 drivers/staging/line6/variax.h   |  2 +-
 9 files changed, 24 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 4bfef21..08f8051 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -959,33 +959,26 @@ static int line6_probe(struct usb_interface *interface,
case LINE6_POCKETPOD:
case LINE6_PODXT:
case LINE6_PODXTPRO:
-   ret = line6_pod_init(interface, (struct usb_line6_pod *)line6);
+   ret = line6_pod_init(interface, line6);
break;
 
case LINE6_PODHD300:
case LINE6_PODHD400:
case LINE6_PODHD500_0:
case LINE6_PODHD500_1:
-   ret = line6_podhd_init(interface,
-  (struct usb_line6_podhd *)line6);
+   ret = line6_podhd_init(interface, line6);
break;
 
case LINE6_PODXTLIVE_POD:
-   ret =
-   line6_pod_init(interface,
-  (struct usb_line6_pod *)line6);
+   ret = line6_pod_init(interface, line6);
break;
 
case LINE6_PODXTLIVE_VARIAX:
-   ret =
-   line6_variax_init(interface,
- (struct usb_line6_variax *)line6);
+   ret = line6_variax_init(interface, line6);
break;
 
case LINE6_VARIAX:
-   ret =
-   line6_variax_init(interface,
- (struct usb_line6_variax *)line6);
+   ret = line6_variax_init(interface, line6);
break;
 
case LINE6_PODSTUDIO_GX:
@@ -995,9 +988,7 @@ static int line6_probe(struct usb_interface *interface,
case LINE6_TONEPORT_UX1:
case LINE6_TONEPORT_UX2:
case LINE6_GUITARPORT:
-   ret =
-   line6_toneport_init(interface,
-   (struct usb_line6_toneport *)line6);
+   ret = line6_toneport_init(interface, line6);
break;
 
default:
diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index 0fb1788..9292b72 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -353,10 +353,10 @@ static int pod_create_files2(struct device *dev)
 Try to init POD device.
 */
 static int pod_try_init(struct usb_interface *interface,
-   struct usb_line6_pod *pod)
+   struct usb_line6 *line6)
 {
int err;
-   struct usb_line6 *line6 = >line6;
+   struct usb_line6_pod *pod = (struct usb_line6_pod *) line6;
 
init_timer(>startup_timer);
INIT_WORK(>startup_work, pod_startup4);
@@ -409,9 +409,9 @@ static int pod_try_init(struct usb_interface *interface,
 /*
 Init POD device (and clean up in case of failure).
 */
-int line6_pod_init(struct usb_interface *interface, struct usb_line6_pod *pod)
+int line6_pod_init(struct usb_interface *interface, struct usb_line6 *line6)
 {
-   int err = pod_try_init(interface, pod);
+   int err = pod_try_init(interface, line6);
 
if (err < 0)
pod_destruct(interface);
diff --git a/drivers/staging/line6/pod.h b/drivers/staging/line6/pod.h
index 91fd4c5..cf6c75cd 100644
--- a/drivers/staging/line6/pod.h
+++ b/drivers/staging/line6/pod.h
@@ -88,7 +88,7 @@ struct usb_line6_pod {
 
 extern void line6_pod_disconnect(struct usb_interface *interface);
 extern int line6_pod_init(struct usb_interface *interface,
- struct usb_line6_pod *pod);
+ struct usb_line6 *line6);
 extern void line6_pod_process_message(struct usb_line6_pod *pod);
 
 #endif
diff --git a/drivers/staging/line6/podhd.c b/drivers/staging/line6/podhd.c
index 7ef4543..3bb942e 100644
--- a/drivers/staging/line6/podhd.c
+++ b/drivers/staging/line6/podhd.c
@@ -121,9 +121,9 @@ static int podhd_try_init(struct usb_interface *interface,
 /*
Init POD HD device (and clean up in case of failure).
 */
-int line6_podhd_init(struct usb_interface *interface,
-struct usb_line6_podhd *podhd)
+int line6_podhd_init(struct usb_interface *interface, struct usb_line6 *line6)
 {
+   struct usb_line6_podhd *podhd = (struct usb_line6_podhd *) line6;
int err = 

[PATCH 24/25] staging: line6: Call *_disconnect() via pointer

2015-01-09 Thread Chris Rorvick
Which *_disconnect() to call on disconnect is known at initialization.
Add a function pointer to the `usb_line6' struct and use to call into
the appropriate logic instead of evaluating the conditional logic.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c   | 43 +---
 drivers/staging/line6/driver.h   |  1 +
 drivers/staging/line6/pod.c  |  1 +
 drivers/staging/line6/podhd.c|  2 ++
 drivers/staging/line6/toneport.c |  2 ++
 drivers/staging/line6/variax.c   |  1 +
 6 files changed, 8 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index f7629cb..fc852f6 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -1017,48 +1017,7 @@ static void line6_disconnect(struct usb_interface 
*interface)
dev_err(line6->ifcdev,
"driver bug: inconsistent usb device\n");
 
-   switch (line6->type) {
-   case LINE6_BASSPODXT:
-   case LINE6_BASSPODXTLIVE:
-   case LINE6_BASSPODXTPRO:
-   case LINE6_POCKETPOD:
-   case LINE6_PODXT:
-   case LINE6_PODXTPRO:
-   line6_pod_disconnect(interface);
-   break;
-
-   case LINE6_PODHD300:
-   case LINE6_PODHD400:
-   case LINE6_PODHD500_0:
-   case LINE6_PODHD500_1:
-   line6_podhd_disconnect(interface);
-   break;
-
-   case LINE6_PODXTLIVE_POD:
-   line6_pod_disconnect(interface);
-   break;
-
-   case LINE6_PODXTLIVE_VARIAX:
-   line6_variax_disconnect(interface);
-   break;
-
-   case LINE6_VARIAX:
-   line6_variax_disconnect(interface);
-   break;
-
-   case LINE6_PODSTUDIO_GX:
-   case LINE6_PODSTUDIO_UX1:
-   case LINE6_PODSTUDIO_UX2:
-   case LINE6_TONEPORT_GX:
-   case LINE6_TONEPORT_UX1:
-   case LINE6_TONEPORT_UX2:
-   case LINE6_GUITARPORT:
-   line6_toneport_disconnect(interface);
-   break;
-
-   default:
-   MISSING_CASE;
-   }
+   line6->disconnect(interface);
 
dev_info(>dev, "Line6 %s now disconnected\n",
 line6->properties->name);
diff --git a/drivers/staging/line6/driver.h b/drivers/staging/line6/driver.h
index 220813f..ad203f1 100644
--- a/drivers/staging/line6/driver.h
+++ b/drivers/staging/line6/driver.h
@@ -196,6 +196,7 @@ struct usb_line6 {
int message_length;
 
void (*process_message)(struct usb_line6 *);
+   void (*disconnect)(struct usb_interface *);
 };
 
 extern char *line6_alloc_sysex_buffer(struct usb_line6 *line6, int code1,
diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index 79dcff4..b9af5cf 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -360,6 +360,7 @@ static int pod_try_init(struct usb_interface *interface,
struct usb_line6_pod *pod = (struct usb_line6_pod *) line6;
 
line6->process_message = line6_pod_process_message;
+   line6->disconnect = line6_pod_disconnect;
 
init_timer(>startup_timer);
INIT_WORK(>startup_work, pod_startup4);
diff --git a/drivers/staging/line6/podhd.c b/drivers/staging/line6/podhd.c
index 3bb942e..a57fbce 100644
--- a/drivers/staging/line6/podhd.c
+++ b/drivers/staging/line6/podhd.c
@@ -98,6 +98,8 @@ static int podhd_try_init(struct usb_interface *interface,
if ((interface == NULL) || (podhd == NULL))
return -ENODEV;
 
+   line6->disconnect = line6_podhd_disconnect;
+
/* initialize audio system: */
err = line6_init_audio(line6);
if (err < 0)
diff --git a/drivers/staging/line6/toneport.c b/drivers/staging/line6/toneport.c
index 70fba02..42c34eb 100644
--- a/drivers/staging/line6/toneport.c
+++ b/drivers/staging/line6/toneport.c
@@ -347,6 +347,8 @@ static int toneport_try_init(struct usb_interface 
*interface,
if ((interface == NULL) || (toneport == NULL))
return -ENODEV;
 
+   line6->disconnect = line6_toneport_disconnect;
+
/* initialize audio system: */
err = line6_init_audio(line6);
if (err < 0)
diff --git a/drivers/staging/line6/variax.c b/drivers/staging/line6/variax.c
index ccb1f68..ca25b41 100644
--- a/drivers/staging/line6/variax.c
+++ b/drivers/staging/line6/variax.c
@@ -181,6 +181,7 @@ static int variax_try_init(struct usb_interface *interface,
int err;
 
line6->process_message = line6_variax_process_message;
+   line6->disconnect = line6_variax_disconnect;
 
init_timer(>startup_timer1);

[PATCH 22/25] staging: line6: Pass *_process_message() `usb_line6' pointers

2015-01-09 Thread Chris Rorvick
Casting the `struct usb_line6' pointer at the call point makes the code
difficult to read.  This is substantially cleaned up by moving the cast
into the callees.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 13 -
 drivers/staging/line6/pod.c|  3 ++-
 drivers/staging/line6/pod.h|  2 +-
 drivers/staging/line6/variax.c |  3 ++-
 drivers/staging/line6/variax.h |  2 +-
 5 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 08f8051..369e60e 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -544,8 +544,7 @@ static void line6_data_received(struct urb *urb)
case LINE6_PODXT:
case LINE6_PODXTPRO:
case LINE6_POCKETPOD:
-   line6_pod_process_message((struct usb_line6_pod *)
- line6);
+   line6_pod_process_message(line6);
break;
 
case LINE6_PODHD300:
@@ -555,19 +554,15 @@ static void line6_data_received(struct urb *urb)
break; /* let userspace handle MIDI */
 
case LINE6_PODXTLIVE_POD:
-   line6_pod_process_message((struct usb_line6_pod
-  *)line6);
+   line6_pod_process_message(line6);
break;
 
case LINE6_PODXTLIVE_VARIAX:
-   line6_variax_process_message((struct
- usb_line6_variax
- *)line6);
+   line6_variax_process_message(line6);
break;
 
case LINE6_VARIAX:
-   line6_variax_process_message((struct usb_line6_variax *)
-line6);
+   line6_variax_process_message(line6);
break;
 
default:
diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index 9292b72..aa8977d 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -131,8 +131,9 @@ static char *pod_alloc_sysex_buffer(struct usb_line6_pod 
*pod, int code,
 /*
Process a completely received message.
 */
-void line6_pod_process_message(struct usb_line6_pod *pod)
+void line6_pod_process_message(struct usb_line6 *line6)
 {
+   struct usb_line6_pod *pod = (struct usb_line6_pod *) line6;
const unsigned char *buf = pod->line6.buffer_message;
 
if (memcmp(buf, pod_version_header, sizeof(pod_version_header)) == 0) {
diff --git a/drivers/staging/line6/pod.h b/drivers/staging/line6/pod.h
index cf6c75cd..984a00b 100644
--- a/drivers/staging/line6/pod.h
+++ b/drivers/staging/line6/pod.h
@@ -89,6 +89,6 @@ struct usb_line6_pod {
 extern void line6_pod_disconnect(struct usb_interface *interface);
 extern int line6_pod_init(struct usb_interface *interface,
  struct usb_line6 *line6);
-extern void line6_pod_process_message(struct usb_line6_pod *pod);
+extern void line6_pod_process_message(struct usb_line6 *line6);
 
 #endif
diff --git a/drivers/staging/line6/variax.c b/drivers/staging/line6/variax.c
index f5b618b..4d41994 100644
--- a/drivers/staging/line6/variax.c
+++ b/drivers/staging/line6/variax.c
@@ -130,8 +130,9 @@ static void variax_startup6(struct work_struct *work)
 /*
Process a completely received message.
 */
-void line6_variax_process_message(struct usb_line6_variax *variax)
+void line6_variax_process_message(struct usb_line6 *line6)
 {
+   struct usb_line6_variax *variax = (struct usb_line6_variax *) line6;
const unsigned char *buf = variax->line6.buffer_message;
 
switch (buf[0]) {
diff --git a/drivers/staging/line6/variax.h b/drivers/staging/line6/variax.h
index 9bf1464..7d445ff 100644
--- a/drivers/staging/line6/variax.h
+++ b/drivers/staging/line6/variax.h
@@ -67,6 +67,6 @@ struct usb_line6_variax {
 extern void line6_variax_disconnect(struct usb_interface *interface);
 extern int line6_variax_init(struct usb_interface *interface,
 struct usb_line6 *line6);
-extern void line6_variax_process_message(struct usb_line6_variax *variax);
+extern void line6_variax_process_message(struct usb_line6 *line6);
 
 #endif
-- 
2.1.0

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


[PATCH 23/25] staging: line6: Call *_process_message() via pointer

2015-01-09 Thread Chris Rorvick
Which *_process_message() function (if any) to call when data is
received is known at initialization.  Add a function pointer to the
`usb_line6' struct and use to call into the appropriate logic instead
of evaluating the conditional logic for each message.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 33 ++---
 drivers/staging/line6/driver.h |  2 ++
 drivers/staging/line6/pod.c|  4 +++-
 drivers/staging/line6/pod.h|  1 -
 drivers/staging/line6/variax.c |  4 +++-
 drivers/staging/line6/variax.h |  1 -
 6 files changed, 10 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 369e60e..f7629cb 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -537,37 +537,8 @@ static void line6_data_received(struct urb *urb)
line6->message_length = done;
line6_midi_receive(line6, line6->buffer_message, done);
 
-   switch (line6->type) {
-   case LINE6_BASSPODXT:
-   case LINE6_BASSPODXTLIVE:
-   case LINE6_BASSPODXTPRO:
-   case LINE6_PODXT:
-   case LINE6_PODXTPRO:
-   case LINE6_POCKETPOD:
-   line6_pod_process_message(line6);
-   break;
-
-   case LINE6_PODHD300:
-   case LINE6_PODHD400:
-   case LINE6_PODHD500_0:
-   case LINE6_PODHD500_1:
-   break; /* let userspace handle MIDI */
-
-   case LINE6_PODXTLIVE_POD:
-   line6_pod_process_message(line6);
-   break;
-
-   case LINE6_PODXTLIVE_VARIAX:
-   line6_variax_process_message(line6);
-   break;
-
-   case LINE6_VARIAX:
-   line6_variax_process_message(line6);
-   break;
-
-   default:
-   MISSING_CASE;
-   }
+   if (line6->process_message)
+   line6->process_message(line6);
}
 
line6_start_listen(line6);
diff --git a/drivers/staging/line6/driver.h b/drivers/staging/line6/driver.h
index a4bde71..220813f 100644
--- a/drivers/staging/line6/driver.h
+++ b/drivers/staging/line6/driver.h
@@ -194,6 +194,8 @@ struct usb_line6 {
 Length of message to be processed.
*/
int message_length;
+
+   void (*process_message)(struct usb_line6 *);
 };
 
 extern char *line6_alloc_sysex_buffer(struct usb_line6 *line6, int code1,
diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index aa8977d..79dcff4 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -131,7 +131,7 @@ static char *pod_alloc_sysex_buffer(struct usb_line6_pod 
*pod, int code,
 /*
Process a completely received message.
 */
-void line6_pod_process_message(struct usb_line6 *line6)
+static void line6_pod_process_message(struct usb_line6 *line6)
 {
struct usb_line6_pod *pod = (struct usb_line6_pod *) line6;
const unsigned char *buf = pod->line6.buffer_message;
@@ -359,6 +359,8 @@ static int pod_try_init(struct usb_interface *interface,
int err;
struct usb_line6_pod *pod = (struct usb_line6_pod *) line6;
 
+   line6->process_message = line6_pod_process_message;
+
init_timer(>startup_timer);
INIT_WORK(>startup_work, pod_startup4);
 
diff --git a/drivers/staging/line6/pod.h b/drivers/staging/line6/pod.h
index 984a00b..0d78ca7 100644
--- a/drivers/staging/line6/pod.h
+++ b/drivers/staging/line6/pod.h
@@ -89,6 +89,5 @@ struct usb_line6_pod {
 extern void line6_pod_disconnect(struct usb_interface *interface);
 extern int line6_pod_init(struct usb_interface *interface,
  struct usb_line6 *line6);
-extern void line6_pod_process_message(struct usb_line6 *line6);
 
 #endif
diff --git a/drivers/staging/line6/variax.c b/drivers/staging/line6/variax.c
index 4d41994..ccb1f68 100644
--- a/drivers/staging/line6/variax.c
+++ b/drivers/staging/line6/variax.c
@@ -130,7 +130,7 @@ static void variax_startup6(struct work_struct *work)
 /*
Process a completely received message.
 */
-void line6_variax_process_message(struct usb_line6 *line6)
+static void line6_variax_process_message(struct usb_line6 *line6)
 {
struct usb_line6_variax *variax = (struct usb_line6_variax *) line6;
const unsigned char *buf = variax->line6.buffer_message;
@@ -180,6 +180,8 @@ static int variax_try_init(struct usb_interface *interface,
struct usb_line6_variax *variax = (struct usb_line6_variax *) line6;
int err;
 
+   line6->process_message = line6_variax_process_message;
+
init_timer(>startup_timer1);
init_timer(>startup_timer2);
INIT_WORK(>startup_work, variax_startup6);
diff --git a/drivers/staging/line6/variax.h 

[PATCH 25/25] staging: line6: Make *_disconnect() functions static

2015-01-09 Thread Chris Rorvick
Remove declarations from the header and move the definitions up in the
source so they need not be forward declared.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/pod.c  | 58 ++--
 drivers/staging/line6/pod.h  |  1 -
 drivers/staging/line6/podhd.c| 42 +--
 drivers/staging/line6/podhd.h|  1 -
 drivers/staging/line6/toneport.c | 63 +---
 drivers/staging/line6/toneport.h |  1 -
 drivers/staging/line6/variax.c   | 22 +++---
 drivers/staging/line6/variax.h   |  1 -
 8 files changed, 94 insertions(+), 95 deletions(-)

diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index b9af5cf..85a4363 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -338,6 +338,35 @@ static void pod_destruct(struct usb_interface *interface)
 }
 
 /*
+   POD device disconnected.
+*/
+static void line6_pod_disconnect(struct usb_interface *interface)
+{
+   struct usb_line6_pod *pod;
+
+   if (interface == NULL)
+   return;
+   pod = usb_get_intfdata(interface);
+
+   if (pod != NULL) {
+   struct snd_line6_pcm *line6pcm = pod->line6.line6pcm;
+   struct device *dev = >dev;
+
+   if (line6pcm != NULL)
+   line6_pcm_disconnect(line6pcm);
+
+   if (dev != NULL) {
+   /* remove sysfs entries: */
+   device_remove_file(dev, _attr_device_id);
+   device_remove_file(dev, _attr_firmware_version);
+   device_remove_file(dev, _attr_serial_number);
+   }
+   }
+
+   pod_destruct(interface);
+}
+
+/*
Create sysfs entries.
 */
 static int pod_create_files2(struct device *dev)
@@ -422,32 +451,3 @@ int line6_pod_init(struct usb_interface *interface, struct 
usb_line6 *line6)
 
return err;
 }
-
-/*
-   POD device disconnected.
-*/
-void line6_pod_disconnect(struct usb_interface *interface)
-{
-   struct usb_line6_pod *pod;
-
-   if (interface == NULL)
-   return;
-   pod = usb_get_intfdata(interface);
-
-   if (pod != NULL) {
-   struct snd_line6_pcm *line6pcm = pod->line6.line6pcm;
-   struct device *dev = >dev;
-
-   if (line6pcm != NULL)
-   line6_pcm_disconnect(line6pcm);
-
-   if (dev != NULL) {
-   /* remove sysfs entries: */
-   device_remove_file(dev, _attr_device_id);
-   device_remove_file(dev, _attr_firmware_version);
-   device_remove_file(dev, _attr_serial_number);
-   }
-   }
-
-   pod_destruct(interface);
-}
diff --git a/drivers/staging/line6/pod.h b/drivers/staging/line6/pod.h
index 0d78ca7..87a8f0f 100644
--- a/drivers/staging/line6/pod.h
+++ b/drivers/staging/line6/pod.h
@@ -86,7 +86,6 @@ struct usb_line6_pod {
int device_id;
 };
 
-extern void line6_pod_disconnect(struct usb_interface *interface);
 extern int line6_pod_init(struct usb_interface *interface,
  struct usb_line6 *line6);
 
diff --git a/drivers/staging/line6/podhd.c b/drivers/staging/line6/podhd.c
index a57fbce..27c5402 100644
--- a/drivers/staging/line6/podhd.c
+++ b/drivers/staging/line6/podhd.c
@@ -87,6 +87,27 @@ static void podhd_destruct(struct usb_interface *interface)
 }
 
 /*
+   POD HD device disconnected.
+*/
+static void line6_podhd_disconnect(struct usb_interface *interface)
+{
+   struct usb_line6_podhd *podhd;
+
+   if (interface == NULL)
+   return;
+   podhd = usb_get_intfdata(interface);
+
+   if (podhd != NULL) {
+   struct snd_line6_pcm *line6pcm = podhd->line6.line6pcm;
+
+   if (line6pcm != NULL)
+   line6_pcm_disconnect(line6pcm);
+   }
+
+   podhd_destruct(interface);
+}
+
+/*
Try to init POD HD device.
 */
 static int podhd_try_init(struct usb_interface *interface,
@@ -133,24 +154,3 @@ int line6_podhd_init(struct usb_interface *interface, 
struct usb_line6 *line6)
 
return err;
 }
-
-/*
-   POD HD device disconnected.
-*/
-void line6_podhd_disconnect(struct usb_interface *interface)
-{
-   struct usb_line6_podhd *podhd;
-
-   if (interface == NULL)
-   return;
-   podhd = usb_get_intfdata(interface);
-
-   if (podhd != NULL) {
-   struct snd_line6_pcm *line6pcm = podhd->line6.line6pcm;
-
-   if (line6pcm != NULL)
-   line6_pcm_disconnect(line6pcm);
-   }
-
-   podhd_destruct(interface);
-}
diff --git a/drivers/staging/line6/podhd.h b/drivers/staging/line6/podhd.h
index b7d9568..a14f711 100644
--- a/drivers/staging/line6/podhd.h
+++ b/drivers/staging/line6/podhd.h
@@ -23,7 +23,6 @@ struct usb_line6_podhd {
struct usb_line6 line6;
 };
 
-extern void 

[PATCH 06/25] staging: line6: Index properties array with device type

2015-01-09 Thread Chris Rorvick
The current logic uses the index of the matched entry from the device
table as an offset to the corresponding properties entry.  The values
of the new `line6_device_type' enum are ordered such that they can be
used as an index into either of these arrays.  Drop the device entry
lookup logic and use the device type (via the .driver_info member)
instead.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 2797e41..c090b2b 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -624,7 +624,7 @@ static void line6_destruct(struct usb_interface *interface)
 static int line6_probe(struct usb_interface *interface,
   const struct usb_device_id *id)
 {
-   int devtype;
+   enum line6_device_type devtype;
struct usb_device *usbdev;
struct usb_line6 *line6;
const struct line6_properties *properties;
@@ -646,20 +646,7 @@ static int line6_probe(struct usb_interface *interface,
goto err_put;
}
 
-   /* check vendor and product id */
-   for (devtype = ARRAY_SIZE(line6_id_table) - 1; devtype--;) {
-   u16 idVendor = le16_to_cpu(usbdev->descriptor.idVendor);
-   u16 idProduct = le16_to_cpu(usbdev->descriptor.idProduct);
-
-   if (idVendor == line6_id_table[devtype].idVendor &&
-   idProduct == line6_id_table[devtype].idProduct)
-   break;
-   }
-
-   if (devtype < 0) {
-   ret = -ENODEV;
-   goto err_put;
-   }
+   devtype = id->driver_info;
 
/* initialize device info: */
properties = _properties_table[devtype];
-- 
2.1.0

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


[PATCH 02/25] staging: line6: Remove line6_pod_transmit_paramter()

2015-01-09 Thread Chris Rorvick
This function was no longer used as of commit 2807904441d4 (staging:
line6: drop MIDI parameter sysfs attrs).

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/pod.c | 9 -
 drivers/staging/line6/pod.h | 2 --
 2 files changed, 11 deletions(-)

diff --git a/drivers/staging/line6/pod.c b/drivers/staging/line6/pod.c
index 44f4b2f..7b4ec92f 100644
--- a/drivers/staging/line6/pod.c
+++ b/drivers/staging/line6/pod.c
@@ -159,15 +159,6 @@ void line6_pod_process_message(struct usb_line6_pod *pod)
 }
 
 /*
-   Transmit PODxt Pro control parameter.
-*/
-void line6_pod_transmit_parameter(struct usb_line6_pod *pod, int param,
- u8 value)
-{
-   line6_transmit_parameter(>line6, param, value);
-}
-
-/*
Send system parameter (from integer).
 */
 static int pod_set_system_param_int(struct usb_line6_pod *pod, int value,
diff --git a/drivers/staging/line6/pod.h b/drivers/staging/line6/pod.h
index 3e3f167..397d94c 100644
--- a/drivers/staging/line6/pod.h
+++ b/drivers/staging/line6/pod.h
@@ -96,7 +96,5 @@ extern void line6_pod_disconnect(struct usb_interface 
*interface);
 extern int line6_pod_init(struct usb_interface *interface,
  struct usb_line6_pod *pod);
 extern void line6_pod_process_message(struct usb_line6_pod *pod);
-extern void line6_pod_transmit_parameter(struct usb_line6_pod *pod, int param,
-u8 value);
 
 #endif
-- 
2.1.0

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


[PATCH 01/25] staging: line6: Remove `device_bit' from properties

2015-01-09 Thread Chris Rorvick
The `device_bit' member was no longer used as of commit 2807904441d4
(staging: line6: drop MIDI parameter sysfs attrs).

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c  | 44 +++---
 drivers/staging/line6/driver.h  |  5 
 drivers/staging/line6/pcm.h |  2 ++
 drivers/staging/line6/usbdefs.h | 59 -
 4 files changed, 24 insertions(+), 86 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 503b2d7..15f3bc4 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -57,32 +57,32 @@ static const struct usb_device_id line6_id_table[] = {
 
 MODULE_DEVICE_TABLE(usb, line6_id_table);
 
-#define L6PROP(dev_bit, dev_id, dev_name, dev_cap)\
-   {.device_bit = LINE6_BIT_##dev_bit, .id = dev_id,\
+#define L6PROP(dev_id, dev_name, dev_cap)\
+   {.id = dev_id,\
 .name = dev_name, .capabilities = LINE6_BIT_##dev_cap}
 
 /* *INDENT-OFF* */
 static const struct line6_properties line6_properties_table[] = {
-   L6PROP(BASSPODXT, "BassPODxt", "BassPODxt",CTRL_PCM_HW),
-   L6PROP(BASSPODXTLIVE, "BassPODxtLive", "BassPODxt Live",   CTRL_PCM_HW),
-   L6PROP(BASSPODXTPRO,  "BassPODxtPro",  "BassPODxt Pro",CTRL_PCM_HW),
-   L6PROP(GUITARPORT,"GuitarPort","GuitarPort",   PCM),
-   L6PROP(POCKETPOD, "PocketPOD", "Pocket POD",   CONTROL),
-   L6PROP(PODHD300,  "PODHD300",  "POD HD300",CTRL_PCM_HW),
-   L6PROP(PODHD400,  "PODHD400",  "POD HD400",CTRL_PCM_HW),
-   L6PROP(PODHD500,  "PODHD500",  "POD HD500",CTRL_PCM_HW),
-   L6PROP(PODSTUDIO_GX,  "PODStudioGX",   "POD Studio GX",PCM),
-   L6PROP(PODSTUDIO_UX1, "PODStudioUX1",  "POD Studio UX1",   PCM),
-   L6PROP(PODSTUDIO_UX2, "PODStudioUX2",  "POD Studio UX2",   PCM),
-   L6PROP(PODX3, "PODX3", "POD X3",   PCM),
-   L6PROP(PODX3LIVE, "PODX3Live", "POD X3 Live",  PCM),
-   L6PROP(PODXT, "PODxt", "PODxt",CTRL_PCM_HW),
-   L6PROP(PODXTLIVE, "PODxtLive", "PODxt Live",   CTRL_PCM_HW),
-   L6PROP(PODXTPRO,  "PODxtPro",  "PODxt Pro",CTRL_PCM_HW),
-   L6PROP(TONEPORT_GX,   "TonePortGX","TonePort GX",  PCM),
-   L6PROP(TONEPORT_UX1,  "TonePortUX1",   "TonePort UX1", PCM),
-   L6PROP(TONEPORT_UX2,  "TonePortUX2",   "TonePort UX2", PCM),
-   L6PROP(VARIAX,"Variax","Variax Workbench", CONTROL),
+   L6PROP("BassPODxt", "BassPODxt",CTRL_PCM_HW),
+   L6PROP("BassPODxtLive", "BassPODxt Live",   CTRL_PCM_HW),
+   L6PROP("BassPODxtPro",  "BassPODxt Pro",CTRL_PCM_HW),
+   L6PROP("GuitarPort","GuitarPort",   PCM),
+   L6PROP("PocketPOD", "Pocket POD",   CONTROL),
+   L6PROP("PODHD300",  "POD HD300",CTRL_PCM_HW),
+   L6PROP("PODHD400",  "POD HD400",CTRL_PCM_HW),
+   L6PROP("PODHD500",  "POD HD500",CTRL_PCM_HW),
+   L6PROP("PODStudioGX",   "POD Studio GX",PCM),
+   L6PROP("PODStudioUX1",  "POD Studio UX1",   PCM),
+   L6PROP("PODStudioUX2",  "POD Studio UX2",   PCM),
+   L6PROP("PODX3", "POD X3",   PCM),
+   L6PROP("PODX3Live", "POD X3 Live",  PCM),
+   L6PROP("PODxt", "PODxt",CTRL_PCM_HW),
+   L6PROP("PODxtLive", "PODxt Live",   CTRL_PCM_HW),
+   L6PROP("PODxtPro",  "PODxt Pro",CTRL_PCM_HW),
+   L6PROP("TonePortGX","TonePort GX",  PCM),
+   L6PROP("TonePortUX1",   "TonePort UX1", PCM),
+   L6PROP("TonePortUX2",   "TonePort UX2", PCM),
+   L6PROP("Variax","Variax Workbench", CONTROL),
 };
 /* *INDENT-ON* */
 
diff --git a/drivers/staging/line6/driver.h b/drivers/staging/line6/driver.h
index 16e3fc2..1cc7532 100644
--- a/drivers/staging/line6/driver.h
+++ b/drivers/staging/line6/driver.h
@@ -76,11 +76,6 @@ static const int SYSEX_EXTRA_SIZE = sizeof(line6_midi_id) + 
4;
 */
 struct line6_properties {
/**
-Bit identifying this device in the line6usb driver.
-   */
-   int device_bit;
-
-   /**
 Card id string (maximum 16 characters).
 This can be used to address the device in ALSA programs as
 "default:CARD="
diff --git a/drivers/staging/line6/pcm.h b/drivers/staging/line6/pcm.h
index 6aa0d46..5716f16 100644
--- a/drivers/staging/line6/pcm.h
+++ b/drivers/staging/line6/pcm.h
@@ -98,6 +98,8 @@ enum {
LINE6_INDEX_PAUSE_PLAYBACK,
LINE6_INDEX_PREPARED,
 
+#define LINE6_BIT(x) LINE6_BIT_ ## x = 1 << LINE6_INDEX_ ## x
+
/* individual bit masks: */
LINE6_BIT(PCM_ALSA_PLAYBACK_BUFFER),
LINE6_BIT(PCM_ALSA_PLAYBACK_STREAM),
diff --git a/drivers/staging/line6/usbdefs.h 

[PATCH 00/25] line6usb cleanup

2015-01-09 Thread Chris Rorvick
The line6usb driver references the device's idProduct and, in some
cases, the interface number in a number of places to determine device-
specific configuration values and to call device-specific functionality.
Rework code to leverage the device table matching more effectively.
Consolidate configuration settings into the properties entries and use
function pointers setup at initialization to remove much of the
conditional logic.

I have a TonePort UX2 that I've used for testing, meaning that some of
this is really only compile-tested.

Regards,

Chris

Chris Rorvick (25):
  staging: line6: Remove `device_bit' from properties
  staging: line6: Remove line6_pod_transmit_paramter()
  staging: line6: Remove unsupported X3 devices
  staging: line6: Cleanup device table
  staging: line6: Define a device type enum
  staging: line6: Index properties array with device type
  staging: line6: Key off of device type
  staging: line6: Remove idVendor and idProduct macros
  staging: line6: Remove useless comments
  staging: line6: Rename capability macros
  staging: line6: Use explicit indexes when defining properties
  staging: line6: List out capabilities individually
  staging: line6: Split out PODxt Live interfaces
  staging: line6: Split out POD HD500 interfaces
  staging: line6: Filter on Pocket POD interface
  staging: line6: Filter on UX2 interfaces
  staging: line6: Move altsetting to properties
  staging: line6: Move control endpoints to properties
  staging: line6: Remove stale Pocket POD PCM endpoints
  staging: line6: Move audio endpoints to properties
  staging: line6: Pass *_init() `usb_line6' pointers
  staging: line6: Pass *_process_message() `usb_line6' pointers
  staging: line6: Call *_process_message() via pointer
  staging: line6: Call *_disconnect() via pointer
  staging: line6: Make *_disconnect() functions static

 drivers/staging/line6/capture.c  |   9 +-
 drivers/staging/line6/driver.c   | 698 ++-
 drivers/staging/line6/driver.h   |  57 ++--
 drivers/staging/line6/midi.c |   4 +-
 drivers/staging/line6/pcm.c  |  55 +--
 drivers/staging/line6/pcm.h  |  12 +-
 drivers/staging/line6/playback.c |  11 +-
 drivers/staging/line6/pod.c  |  83 +++--
 drivers/staging/line6/pod.h  |  12 +-
 drivers/staging/line6/podhd.c|  48 +--
 drivers/staging/line6/podhd.h|   3 +-
 drivers/staging/line6/toneport.c | 113 ---
 drivers/staging/line6/toneport.h |   3 +-
 drivers/staging/line6/usbdefs.h  |  95 +-
 drivers/staging/line6/variax.c   |  36 +-
 drivers/staging/line6/variax.h   |   4 +-
 16 files changed, 528 insertions(+), 715 deletions(-)

-- 
2.1.0

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


[PATCH 15/25] staging: line6: Filter on Pocket POD interface

2015-01-09 Thread Chris Rorvick
The driver only supports interface 1 of the Pocket POD.  Use the device
table to filter on this.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/line6/driver.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index e97e2cb..8b03bc0 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -39,7 +39,7 @@ static const struct usb_device_id line6_id_table[] = {
{ LINE6_DEVICE(0x4642),.driver_info = LINE6_BASSPODXTLIVE },
{ LINE6_DEVICE(0x4252),.driver_info = LINE6_BASSPODXTPRO },
{ LINE6_DEVICE(0x4750),.driver_info = LINE6_GUITARPORT },
-   { LINE6_DEVICE(0x5051),.driver_info = LINE6_POCKETPOD },
+   { LINE6_IF_NUM(0x5051, 1), .driver_info = LINE6_POCKETPOD },
{ LINE6_DEVICE(0x5057),.driver_info = LINE6_PODHD300 },
{ LINE6_DEVICE(0x5058),.driver_info = LINE6_PODHD400 },
{ LINE6_IF_NUM(0x414D, 0), .driver_info = LINE6_PODHD500_0 },
@@ -738,15 +738,7 @@ static int line6_probe(struct usb_interface *interface,
break;
 
case LINE6_POCKETPOD:
-   switch (interface_number) {
-   case 0:
-   return -ENODEV; /* this interface has no endpoints */
-   case 1:
-   alternate = 0;
-   break;
-   default:
-   MISSING_CASE;
-   }
+   alternate = 0;
break;
 
case LINE6_PODHD500_0:
-- 
2.1.0

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


[PATCH RESEND 2/5] Tools: hv: remove unused bytes_written from kvp_update_file()

2015-01-09 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov 

fwrite() does not actually return the number of bytes written and
this value is being ignored anyway and ferror() is being called to
check for an error. As we assign to this variable and never use it
we get the following compile-time warning:
hv_kvp_daemon.c:149:9: warning: variable .bytes_written. set but not used 
[-Wunused-but-set-variable]
Remove bytes_written completely.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_kvp_daemon.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 6a6432a..5a274ca 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -147,7 +147,6 @@ static void kvp_release_lock(int pool)
 static void kvp_update_file(int pool)
 {
FILE *filep;
-   size_t bytes_written;
 
/*
 * We are going to write our in-memory registry out to
@@ -163,8 +162,7 @@ static void kvp_update_file(int pool)
exit(EXIT_FAILURE);
}
 
-   bytes_written = fwrite(kvp_file_info[pool].records,
-   sizeof(struct kvp_record),
+   fwrite(kvp_file_info[pool].records, sizeof(struct kvp_record),
kvp_file_info[pool].num_records, filep);
 
if (ferror(filep) || fclose(filep)) {
-- 
1.7.4.1

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


[PATCH RESEND 4/5] Tools: hv: address compiler warnings for hv_fcopy_daemon.c

2015-01-09 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov 

This patch addresses two types of compiler warnings:
... warning: unused variable .fd. [-Wunused-variable]
and
... warning: format .%s. expects argument of type .char *., but argument 5 has 
type .__u16 *. [-Wformat=]

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_fcopy_daemon.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index f437d73..1a23872 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -51,7 +51,7 @@ static int hv_start_fcopy(struct hv_start_fcopy *smsg)
 
p = (char *)smsg->path_name;
snprintf(target_fname, sizeof(target_fname), "%s/%s",
-   (char *)smsg->path_name, smsg->file_name);
+(char *)smsg->path_name, (char *)smsg->file_name);
 
syslog(LOG_INFO, "Target file name: %s", target_fname);
/*
@@ -137,7 +137,7 @@ void print_usage(char *argv[])
 
 int main(int argc, char *argv[])
 {
-   int fd, fcopy_fd, len;
+   int fcopy_fd, len;
int error;
int daemonize = 1, long_index = 0, opt;
int version = FCOPY_CURRENT_VERSION;
-- 
1.7.4.1

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


[PATCH RESEND 5/5] Tools: hv: do not add redundant '/' in hv_start_fcopy()

2015-01-09 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov 

We don't need to add additional '/' to smsg->path_name as snprintf("%s/%s")
does the right thing. Without the patch we get doubled '//' in the log message.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_fcopy_daemon.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index 1a23872..9445d8f 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -43,12 +43,6 @@ static int hv_start_fcopy(struct hv_start_fcopy *smsg)
int error = HV_E_FAIL;
char *q, *p;
 
-   /*
-* If possile append a path seperator to the path.
-*/
-   if (strlen((char *)smsg->path_name) < (W_MAX_PATH - 2))
-   strcat((char *)smsg->path_name, "/");
-
p = (char *)smsg->path_name;
snprintf(target_fname, sizeof(target_fname), "%s/%s",
 (char *)smsg->path_name, (char *)smsg->file_name);
-- 
1.7.4.1

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


[PATCH RESEND 1/5] Tools: hv: add mising fcopyd to the Makefile

2015-01-09 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov 

fcopyd in missing in the Makefile, add it there.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/Makefile |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index bd22f78..99ffe61 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -5,9 +5,9 @@ PTHREAD_LIBS = -lpthread
 WARNINGS = -Wall -Wextra
 CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS)
 
-all: hv_kvp_daemon hv_vss_daemon
+all: hv_kvp_daemon hv_vss_daemon hv_fcopy_daemon
 %: %.c
$(CC) $(CFLAGS) -o $@ $^
 
 clean:
-   $(RM) hv_kvp_daemon hv_vss_daemon
+   $(RM) hv_kvp_daemon hv_vss_daemon hv_fcopy_daemon
-- 
1.7.4.1

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


[PATCH RESEND 3/5] Tools: hv: address compiler warnings for hv_kvp_daemon.c

2015-01-09 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov 

This patch addresses two types of compiler warnings:
... warning: comparison between signed and unsigned integer expressions 
[-Wsign-compare]
and
... warning: pointer targets in passing argument N of .kvp_ differ in 
signedness [-Wpointer-sign]

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_kvp_daemon.c |   25 -
 1 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 5a274ca..48a95f9 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -308,7 +308,7 @@ static int kvp_file_init(void)
return 0;
 }
 
-static int kvp_key_delete(int pool, const char *key, int key_size)
+static int kvp_key_delete(int pool, const __u8 *key, int key_size)
 {
int i;
int j, k;
@@ -351,8 +351,8 @@ static int kvp_key_delete(int pool, const char *key, int 
key_size)
return 1;
 }
 
-static int kvp_key_add_or_modify(int pool, const char *key, int key_size, 
const char *value,
-   int value_size)
+static int kvp_key_add_or_modify(int pool, const __u8 *key, int key_size,
+const __u8 *value, int value_size)
 {
int i;
int num_records;
@@ -405,7 +405,7 @@ static int kvp_key_add_or_modify(int pool, const char *key, 
int key_size, const
return 0;
 }
 
-static int kvp_get_value(int pool, const char *key, int key_size, char *value,
+static int kvp_get_value(int pool, const __u8 *key, int key_size, __u8 *value,
int value_size)
 {
int i;
@@ -437,8 +437,8 @@ static int kvp_get_value(int pool, const char *key, int 
key_size, char *value,
return 1;
 }
 
-static int kvp_pool_enumerate(int pool, int index, char *key, int key_size,
-   char *value, int value_size)
+static int kvp_pool_enumerate(int pool, int index, __u8 *key, int key_size,
+   __u8 *value, int value_size)
 {
struct kvp_record *record;
 
@@ -659,7 +659,7 @@ static char *kvp_if_name_to_mac(char *if_name)
char*p, *x;
charbuf[256];
char addr_file[256];
-   int i;
+   unsigned int i;
char *mac_addr = NULL;
 
snprintf(addr_file, sizeof(addr_file), "%s%s%s", "/sys/class/net/",
@@ -698,7 +698,7 @@ static char *kvp_mac_to_if_name(char *mac)
charbuf[256];
char *kvp_net_dir = "/sys/class/net/";
char dev_id[256];
-   int i;
+   unsigned int i;
 
dir = opendir(kvp_net_dir);
if (dir == NULL)
@@ -748,7 +748,7 @@ static char *kvp_mac_to_if_name(char *mac)
 
 
 static void kvp_process_ipconfig_file(char *cmd,
-   char *config_buf, int len,
+   char *config_buf, unsigned int len,
int element_size, int offset)
 {
char buf[256];
@@ -766,7 +766,7 @@ static void kvp_process_ipconfig_file(char *cmd,
if (offset == 0)
memset(config_buf, 0, len);
while ((p = fgets(buf, sizeof(buf), file)) != NULL) {
-   if ((len - strlen(config_buf)) < (element_size + 1))
+   if (len < strlen(config_buf) + element_size + 1)
break;
 
x = strchr(p, '\n');
@@ -914,7 +914,7 @@ static int kvp_process_ip_address(void *addrp,
 
 static int
 kvp_get_ip_info(int family, char *if_name, int op,
-void  *out_buffer, int length)
+void  *out_buffer, unsigned int length)
 {
struct ifaddrs *ifap;
struct ifaddrs *curp;
@@ -1017,8 +1017,7 @@ kvp_get_ip_info(int family, char *if_name, int op,
weight += hweight32([i]);
 
sprintf(cidr_mask, "/%d", weight);
-   if ((length - sn_offset) <
-   (strlen(cidr_mask) + 1))
+   if (length < sn_offset + strlen(cidr_mask) + 1)
goto gather_ipaddr;
 
if (sn_offset == 0)
-- 
1.7.4.1

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


[PATCH RESEND 0/5] Tools: hv: fix compiler warnings and do minor cleanup

2015-01-09 Thread K. Y. Srinivasan
When someone does 'make' in tools/hv/ issues appear:
- hv_fcopy_daemon is not being built;
- lots of compiler warnings.

This is just a cleanup. Compile-tested by myself on top of linux-next/master.

Piggyback this series and send "[PATCH 5/5] Tools: hv: do not add redundant '/'
in hv_start_fcopy()"

Vitaly Kuznetsov (5):
  Tools: hv: add mising fcopyd to the Makefile
  Tools: hv: remove unused bytes_written from kvp_update_file()
  Tools: hv: address compiler warnings for hv_kvp_daemon.c
  Tools: hv: address compiler warnings for hv_fcopy_daemon.c
  Tools: hv: do not add redundant '/' in hv_start_fcopy()

 tools/hv/Makefile  |4 ++--
 tools/hv/hv_fcopy_daemon.c |   10 ++
 tools/hv/hv_kvp_daemon.c   |   29 +
 3 files changed, 17 insertions(+), 26 deletions(-)

-- 
1.7.4.1

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


Re: [PATCH 3.12 78/78] mm: let mm_find_pmd fix buggy race with THP fault

2015-01-09 Thread Hugh Dickins
On Fri, 9 Jan 2015, Jiri Slaby wrote:

> From: Hugh Dickins 
> 
> 3.12-stable review patch.  If anyone has any objections, please let me know.
> 
> ===
> 
> commit f72e7dcdd25229446b102e587ef2f826f76bff28 upstream.
> 
> Trinity has reported:
> 
> BUG: unable to handle kernel NULL pointer dereference at 0018
> IP: __lock_acquire (kernel/locking/lockdep.c:3070 (discriminator 1))
> CPU: 6 PID: 16173 Comm: trinity-c364 Tainted: GW
> 3.15.0-rc1-next-20140415-sasha-00020-gaa90d09 #398
> lock_acquire (arch/x86/include/asm/current.h:14
>   kernel/locking/lockdep.c:3602)
> _raw_spin_lock (include/linux/spinlock_api_smp.h:143
> kernel/locking/spinlock.c:151)
> remove_migration_pte (mm/migrate.c:137)
> rmap_walk (mm/rmap.c:1628 mm/rmap.c:1699)
> remove_migration_ptes (mm/migrate.c:224)
> migrate_pages (mm/migrate.c:922 mm/migrate.c:960 mm/migrate.c:1126)
> migrate_misplaced_page (mm/migrate.c:1733)
> __handle_mm_fault (mm/memory.c:3762 mm/memory.c:3812 mm/memory.c:3925)
> handle_mm_fault (mm/memory.c:3948)
> __get_user_pages (mm/memory.c:1851)
> __mlock_vma_pages_range (mm/mlock.c:255)
> __mm_populate (mm/mlock.c:711)
> SyS_mlockall (include/linux/mm.h:1799 mm/mlock.c:817 mm/mlock.c:791)
> 
> I believe this comes about because, whereas collapsing and splitting THP
> functions take anon_vma lock in write mode (which excludes concurrent
> rmap walks), faulting THP functions (write protection and misplaced
> NUMA) do not - and mostly they do not need to.
> 
> But they do use a pmdp_clear_flush(), set_pmd_at() sequence which, for
> an instant (indeed, for a long instant, given the inter-CPU TLB flush in
> there), leaves *pmd neither present not trans_huge.
> 
> Which can confuse a concurrent rmap walk, as when removing migration
> ptes, seen in the dumped trace.  Although that rmap walk has a 4k page
> to insert, anon_vmas containing THPs are in no way segregated from
> 4k-page anon_vmas, so the 4k-intent mm_find_pmd() does need to cope with
> that instant when a trans_huge pmd is temporarily absent.
> 
> I don't think we need strengthen the locking at the THP end: it's easily
> handled with an ACCESS_ONCE() before testing both conditions.
> 
> And since mm_find_pmd() had only one caller who wanted a THP rather than
> a pmd, let's slightly repurpose it to fail when it hits a THP or
> non-present pmd, and open code split_huge_page_address() again.
> 
> Signed-off-by: Hugh Dickins 
> Reported-by: Sasha Levin 
> Acked-by: Kirill A. Shutemov 
> Cc: Konstantin Khlebnikov 
> Cc: Mel Gorman 
> Cc: Bob Liu 
> Cc: Christoph Lameter 
> Cc: Dave Jones 
> Cc: David Rientjes 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> Signed-off-by: Jiri Slaby 
> ---
>  mm/huge_memory.c | 18 --
>  mm/ksm.c |  1 -
>  mm/migrate.c |  2 --
>  mm/rmap.c| 12 
>  4 files changed, 20 insertions(+), 13 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index e497843f5f65..04d17ba00893 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2408,8 +2408,6 @@ static void collapse_huge_page(struct mm_struct *mm,
>   pmd = mm_find_pmd(mm, address);
>   if (!pmd)
>   goto out;
> - if (pmd_trans_huge(*pmd))
> - goto out;
>  
>   anon_vma_lock_write(vma->anon_vma);
>  
> @@ -2508,8 +2506,6 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
>   pmd = mm_find_pmd(mm, address);
>   if (!pmd)
>   goto out;
> - if (pmd_trans_huge(*pmd))
> - goto out;
>  
>   memset(khugepaged_node_load, 0, sizeof(khugepaged_node_load));
>   pte = pte_offset_map_lock(mm, pmd, address, );
> @@ -2863,12 +2859,22 @@ void split_huge_page_pmd_mm(struct mm_struct *mm, 
> unsigned long address,
>  static void split_huge_page_address(struct mm_struct *mm,
>   unsigned long address)
>  {
> + pgd_t *pgd;
> + pud_t *pud;
>   pmd_t *pmd;
>  
>   VM_BUG_ON(!(address & ~HPAGE_PMD_MASK));
>  
> - pmd = mm_find_pmd(mm, address);
> - if (!pmd)
> + pgd = pgd_offset(mm, address);
> + if (!pgd_present(*pgd))
> + return;
> +
> + pud = pud_offset(pgd, address);
> + if (!pud_present(*pud))
> + return;
> +
> + pmd = pmd_offset(pud, address);
> + if (!pmd_present(*pmd))
>   return;
>   /*
>* Caller holds the mmap_sem write mode, so a huge pmd cannot
> diff --git a/mm/ksm.c b/mm/ksm.c
> index c78fff1e9eae..29cbd06c4884 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -945,7 +945,6 @@ static int replace_page(struct vm_area_struct *vma, 
> struct page *page,
>   pmd = mm_find_pmd(mm, addr);
>   if (!pmd)
>   goto out;
> - BUG_ON(pmd_trans_huge(*pmd));
>  
>   mmun_start = addr;
>   mmun_end   = addr + PAGE_SIZE;
> diff 

[PATCH v7] Staging: comedi: patch to fix line over 80 characters warning

2015-01-09 Thread jitendra kumar khasdev
This is patch to pcl812.c that fix line over 80 characters warning
which is found by checkpatch.pl tool. Reduce the extra space around
equal sign that fix warning.

Signed-off-by: Jitendra kumar khasdev 
---
 drivers/staging/comedi/drivers/pcl812.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/pcl812.c 
b/drivers/staging/comedi/drivers/pcl812.c
index ac243ca..9b576bc 100644
--- a/drivers/staging/comedi/drivers/pcl812.c
+++ b/drivers/staging/comedi/drivers/pcl812.c
@@ -1235,7 +1235,7 @@ static int pcl812_attach(struct comedi_device *dev, 
struct comedi_devconfig *it)
for (i = 0; i < 2; i++) {
unsigned long dmabuf;
 
-   dmabuf =  __get_dma_pages(GFP_KERNEL, 
devpriv->dmapages);
+   dmabuf = __get_dma_pages(GFP_KERNEL, devpriv->dmapages);
if (!dmabuf)
return -ENOMEM;
 
-- 
1.9.1

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


Re: Linux 3.19-rc3

2015-01-09 Thread Linus Torvalds
On Fri, Jan 9, 2015 at 7:29 PM, Laszlo Ersek  wrote:
>
> I've bisected this issue to

.. commit f045bbb9fa1b ("mmu_gather: fix over-eager
tlb_flush_mmu_free() calling")

Hmm. That commit literally just undoes something that commit
fb7332a9fedf ("mmu_gather: move minimal range calculations into
generic code") changed, and that was very wrong on x86.

But arm64 did have very different TLB flushing logic, so there may be
some ARM64 reason that Will did that change originally, and then he
forgot that reason when he ack'ed commit f045bbb9fa1b that undid it.

Will?

Before your mmu_gather range calculations commit, we used to have

In tlb_flush_mmu_tlbonly():

 tlb->need_flush = 0;

and in tlb_flush_mmu():

if (!tlb->need_flush)
return;

and your commit changed the rule to be

!tlb->need_flush == !tlb->end

so in the current tree we have

 In tlb_flush_mmu_tlbonly():

__tlb_reset_range(tlb);   // replaces "tlb->need_flush = 0;"

and in tlb_flush_mmu():

if (!tlb->end)// replaces if (!tlb->need_flush)
return;

so we seem to do exactly the same as 3.18.

But in your original patch, you moved that "if (!tlb->end) return;"
check from tlb_flush_mmu() into tlb_flush_mmu_tlbonly(), and that
apparently is actually needed on arm64. But *why*?

Also, looking at that commit fb7332a9fedf, I note that some of the
"need_flush" setting was simply removed. See for example
arch/powerpc/mm/hugetlbpage.c, and also in mm/memory.c:
tlb_remove_table(). Is there something non-obvious that sets tlb->end
there?

The other need_flush removals seem to all be paired with adding a
__tlb_adjust_range() call, which will set ->end.

I'm starting to suspect that you moved the need_flush test into
tlbonly exactly because you removed that

tlb->need_flush = 1;

from mm/memory.c: tlb_remove_table().

x86 doesn't care, because x86 doesn't *use* tlb_remove_table(). But
arm64 does, at least with the RCU freeing.

Any ideas?

 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 v6] Staging: comedi: patch to fix 80 characters line over warnings

2015-01-09 Thread Greg KH
On Sat, Jan 10, 2015 at 09:54:39AM +0530, jitendra kumar khasdev wrote:
> This is the patch to pcl812.c that fix 80 character line over warnings.
> These warnings are identified by checkpatch.pl tool.
> For this patch I have did following changes,
> 1. convert single line comment into multiline comment
> 2. provide tab sapce for indentation purpose
> 3. reduce extra space between ( = ) sign.

You did 3 things here, so make it 3 different patches please.

thanks,

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


[PATCH v6] Staging: comedi: patch to fix 80 characters line over warnings

2015-01-09 Thread jitendra kumar khasdev
This is the patch to pcl812.c that fix 80 character line over warnings.
These warnings are identified by checkpatch.pl tool.
For this patch I have did following changes,
1. convert single line comment into multiline comment
2. provide tab sapce for indentation purpose
3. reduce extra space between ( = ) sign.

Signed-off-by: Jitendra kumar khasdev 
---
 drivers/staging/comedi/drivers/pcl812.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/comedi/drivers/pcl812.c 
b/drivers/staging/comedi/drivers/pcl812.c
index ac243ca..3eac017 100644
--- a/drivers/staging/comedi/drivers/pcl812.c
+++ b/drivers/staging/comedi/drivers/pcl812.c
@@ -507,20 +507,26 @@ static const struct pcl812_board boardtypes[] = {
 };
 
 struct pcl812_private {
-   unsigned char dma;  /*  >0 use dma ( usedDMA channel) */
+   unsigned char dma;  /*  >0 use dma ( usedDMA channel) */
unsigned char range_correction; /*  =1 we must add 1 to range number */
unsigned int last_ai_chanspec;
-   unsigned char mode_reg_int; /*  there is stored INT number for some 
card */
+   unsigned char mode_reg_int; /*  there is stored INT number for
+*  some card
+*/
unsigned int ai_poll_ptr;   /*  how many sampes transfer poll */
unsigned int dmapages;
unsigned int hwdmasize;
unsigned long dmabuf[2];/*  PTR to DMA buf */
unsigned int hwdmaptr[2];   /*  HW PTR to DMA buf */
unsigned int dmabytestomove[2]; /*  how many bytes DMA transfer */
-   int next_dma_buf;   /*  which buffer is next to use */
-   unsigned int dma_runs_to_end;   /*  how many times we must switch DMA 
buffers */
-   unsigned int last_dma_run;  /*  how many bytes to transfer on last 
DMA buffer */
-   unsigned int max_812_ai_mode0_rangewait;/*  setling time for 
gain */
+   int next_dma_buf;   /*  which buffer is next to use */
+   unsigned int dma_runs_to_end;   /*  how many times we must switch
+*  DMA buffers
+*/
+   unsigned int last_dma_run;  /*  how many bytes to transfer on
+*  last DMA buffer
+*/
+   unsigned int max_812_ai_mode0_rangewait;/* setling time for gain */
unsigned int divisor1;
unsigned int divisor2;
unsigned int use_diff:1;
@@ -1235,7 +1241,7 @@ static int pcl812_attach(struct comedi_device *dev, 
struct comedi_devconfig *it)
for (i = 0; i < 2; i++) {
unsigned long dmabuf;
 
-   dmabuf =  __get_dma_pages(GFP_KERNEL, 
devpriv->dmapages);
+   dmabuf = __get_dma_pages(GFP_KERNEL, devpriv->dmapages);
if (!dmabuf)
return -ENOMEM;
 
-- 
1.9.1

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


Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Al Viro
On Fri, Jan 09, 2015 at 10:41:44PM -0500, Rich Felker wrote:
> > _After_ the traversal it's too late to do this sort of thing - after all,
> > how do you tell if your current position had been set by the traversal of
> > your symlink or that of any normal /proc/self/fd/?
> 
> Thanks for clarifying how this all works in the kernel. It makes it
> easier to understand what the costs (especially complexity costs) of
> different implementation options might be for the kernel.
> 
> > And doing that _during_ the traversal would really suck - stray ls -lR /proc
> > could race with that open() done by script interpreter.
> 
> IMO this one issue is easily solvable by limiting the special action
> to calls by the owning pid.

Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
etc.) before bothering with open(2), you'll get screwed.  Moreover, if it
does so only in case when you have something specific in environment,
you'll have the devil of the time trying to figure out how to reproduce
such a bug report...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Rich Felker
On Sat, Jan 10, 2015 at 03:03:00AM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 11:36:44PM +, Al Viro wrote:
> > On Fri, Jan 09, 2015 at 06:12:48PM -0500, Rich Felker wrote:
> > 
> > > I'm not sure where you're disagreeing with me. open of procfs symlinks
> > > does not resolve the symlink and open the resulting pathname. They are
> > > "magic symlinks" which are bound to the inode of the open file. I
> > > don't see why this action, which is already special for magic
> > > symlinks, can't check a flag on the magic symlink and possibly close
> > > the corresponding file descriptor as part of its action.
> > 
> > _What_ action?  ->follow_link()?  As in "the same thing that e.g.
> > stat(2) would trigger"?
> 
> To elaborate a bit: the fundamental method for symlink traversal is
> ->follow_link().  It gets dentry of the object itself + opaque context.
> Usually it just obtains some string (== symlink contents) and calls
> nd_set_link(context, string).  In that case the string will be interpreted
> by its callers in usual way.  Another possibility is to call
> nd_jump_link(context, location), which will reset the current position
> (directory in which the symlink has been found and relative to which it
> would be interpreted) to given location in tree.  It might actually do
> both - then the string will be interpreted relative to the new location.
> Once the pathname resolution is done with the string stored by nd_set_link(),
> it calls another method - ->put_link().  That one releases the object
> that contains this string; it gets an opaque pointer returned by
> ->follow_link().  Returning ERR_PTR(-Esomething) indicates an error, so does
> nd_set_link(context, ERR_PTR(-Esomething)).
> 
> readlink(2) is using a different method (->readlink()) and any object whose
> ->follow_link() only uses nd_set_link() can use generic_readlink as its
> ->readlink instance - that will call ->follow_link(), copy the string
> stored by nd_set_link() to userland buffer and use ->put_link() to release
> whatever needs to be released.  Most of the symlinks are doing just that.
> 
> procfs "magical" symlinks have ->follow_link() that uses nd_jump_link();
> they obviously can't use generic_readlink() (there is no string left
> by ->follow_link() for caller to traverse), so they have non-standard
> ->readlink() instances - ones that use d_path() to generate a plausible
> pathname of the would-be destination of their ->follow_link().  Or something
> like pipe:[696969], etc.
> 
> Note, however, that ->readlink() is used only by readlink(2) syscall; as far
> as pathname resolution is concerned it is completely irrelevant.  What matters
> is ->follow_link().
> 
> Now, the callers do not know (and do not care) what a particular symlink _is_.
> A symlink is just a dentry with inode that has non-NULL ->follow_link()
> method.  That's it.  Moreover, _any_ pathname resolution is using the
> same method for symlink traversal, be it open(2), stat(2), whatever.  If
> a symlink is to be traversed, that's it - the only choice VFS has is whether
> to traverse it at all or not (think of stat(2) vs lstat(2) difference, or
> O_NOFOLLOW, etc.)
> 
> _After_ the traversal it's too late to do this sort of thing - after all,
> how do you tell if your current position had been set by the traversal of
> your symlink or that of any normal /proc/self/fd/?

Thanks for clarifying how this all works in the kernel. It makes it
easier to understand what the costs (especially complexity costs) of
different implementation options might be for the kernel.

> And doing that _during_ the traversal would really suck - stray ls -lR /proc
> could race with that open() done by script interpreter.

IMO this one issue is easily solvable by limiting the special action
to calls by the owning pid.

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


Re: [PATCH 1/2] lib: devres: add a helper function for ioremap_wc

2015-01-09 Thread Abhilash Kesavan
Hi Greg,

On Thu, Dec 11, 2014 at 8:28 AM, Abhilash Kesavan  wrote:
> Implement a resource managed writecombine ioremap function.
>
> Signed-off-by: Abhilash Kesavan 
> ---
>  Documentation/driver-model/devres.txt |1 +
>  include/linux/io.h|2 ++
>  lib/devres.c  |   28 
>  3 files changed, 31 insertions(+)
>
> diff --git a/Documentation/driver-model/devres.txt 
> b/Documentation/driver-model/devres.txt
> index b5ab416..0f80cee 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -274,6 +274,7 @@ IOMAP
>devm_ioport_unmap()
>devm_ioremap()
>devm_ioremap_nocache()
> +  devm_ioremap_wc()
>devm_ioremap_resource() : checks resource, requests memory region, ioremaps
>devm_iounmap()
>pcim_iomap()
> diff --git a/include/linux/io.h b/include/linux/io.h
> index fa02e55..42b33f0 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -64,6 +64,8 @@ void __iomem *devm_ioremap(struct device *dev, 
> resource_size_t offset,
>resource_size_t size);
>  void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t 
> offset,
>resource_size_t size);
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> +  resource_size_t size);
>  void devm_iounmap(struct device *dev, void __iomem *addr);
>  int check_signature(const volatile void __iomem *io_addr,
> const unsigned char *signature, int length);
> diff --git a/lib/devres.c b/lib/devres.c
> index 0f1dd2e..e8e1738 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
> resource_size_t offset,
>  EXPORT_SYMBOL(devm_ioremap_nocache);
>
>  /**
> + * devm_ioremap_wc - Managed ioremap_wc()
> + * @dev: Generic device to remap IO address for
> + * @offset: BUS offset to map
> + * @size: Size of map
> + *
> + * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
> + */
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> +  resource_size_t size)
> +{
> +   void __iomem **ptr, *addr;
> +
> +   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
> +   if (!ptr)
> +   return NULL;
> +
> +   addr = ioremap_wc(offset, size);

These two patches were applied yesterday to the char-misc tree, but
have broken build on m32r and maybe other platforms too which do not
have ioremap_wc defined. Unfortunately I missed catching this as I
built the patches only for arm64 and arm32, sorry for the trouble.
There was a patch posted a while back which added ioremap_wc for m32r
(https://lkml.org/lkml/2013/6/26/795). I would have to do something
similar for all the other archs which do not have it or is there some
other solution ?

Please drop these patches in the interim so that the build is fixed.

Regards,
Abhilash
> +   if (addr) {
> +   *ptr = addr;
> +   devres_add(dev, ptr);
> +   } else
> +   devres_free(ptr);
> +
> +   return addr;
> +}
> +EXPORT_SYMBOL(devm_ioremap_wc);
> +
> +/**
>   * devm_iounmap - Managed iounmap()
>   * @dev: Generic device to unmap for
>   * @addr: Address to unmap
> --
> 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 3.19-rc3

2015-01-09 Thread Laszlo Ersek
On 01/09/15 20:43, Will Deacon wrote:
> On Fri, Jan 09, 2015 at 06:37:36PM +, Marc Zyngier wrote:
>> On 09/01/15 17:57, Mark Rutland wrote:
>>> On Fri, Jan 09, 2015 at 02:27:06PM +, Mark Langsdorf wrote:
 On 01/09/2015 08:19 AM, Steve Capper wrote:
> On 9 January 2015 at 12:13, Mark Rutland  wrote:
>> On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
>>> I'm consistently getting an out of memory killer triggered when
>>> compiling the kernel (make -j 16 -s) on a 16 core ARM64 system
>>> with 16 GB of memory. This doesn't happen when running a 3.18
>>> kernel.
>>>
>>> I'm going to start bisecting the failure now, but here's the crash
>>> log in case someone can see something obvious in it.
>>
>> FWIW I've just reproduced this with v3.19-rc3 defconfig +
>> CONFIG_ARM64_64K_PAGES=y by attempting a git clone of mainline. My
>> system has 16GB of RAM and 6 CPUs.
> 
> [...]
> 
>>> I wasn't able to trigger the issue again with git, and the only way I've
>>> managed to trigger the issue is repeatedly building the kernel in a
>>> loop:
>>>
>>> while true; do
>>> git clean -fdx > /dev/null 2>&1;
>>> make defconfig > /dev/null 2>&1;
>>> make > /dev/null > 2>&1;
>>> done
>>>
>>> Which after a while died:
>>>
>>> -bash: fork: Cannot allocate memory
> 
> [...]
> 
>> Just as another data point: I'm reproducing the exact same thing (it
>> only took a couple of kernel builds to kill the box), with almost all
>> 16GB of RAM stuck in Active(anon). I do *not* have CMA enabled though.
>>
>> I've kicked another run with 4k pages.
> 
> The `mallocstress' tool from LTP seems to be a quick way to reproduce
> the memory leak behind this (leaks 5/8GB on my Juno). It spawns a bunch
> of threads, that each call malloc until it returns NULL. I thought maybe
> we're leaking page tables, but 5GB is pretty excessive.
> 
> However, I'm unable to reproduce the problem under a 32-bit kernel on my
> TC2 board or on 3.18 + the 3.19 merge window pull for arm64.
> 
> I guess we should try to bisect using the above.
> 
> Will
> 

I've bisected this issue to

> f045bbb9fa1bf6f507ad4de12d4e3471d8f672f1 is the first bad commit
> commit f045bbb9fa1bf6f507ad4de12d4e3471d8f672f1
> Author: Linus Torvalds 
> Date:   Wed Dec 17 11:59:04 2014 -0800
>
> mmu_gather: fix over-eager tlb_flush_mmu_free() calling
>
> Dave Hansen reports that commit fb7332a9fedf ("mmu_gather: move minimal
> range calculations into generic code") caused a performance problem:
>
>   "tlb_finish_mmu() goes up about 9x in the profiles (~0.4%->3.6%) and
>tlb_flush_mmu_free() takes about 3.1% of CPU time with the patch
>applied, but does not show up at all on the commit before"
>
> and the reason is that Will moved the test for whether we need to flush
> from tlb_flush_mmu() into tlb_flush_mmu_tlbonly().  But that meant that
> tlb_flush_mmu_free() basically lost that check.
>
> Move it back into tlb_flush_mmu() where it belongs, so that it covers
> both tlb_flush_mmu_tlbonly() _and_ tlb_flush_mmu_free().
>
> Reported-and-tested-by: Dave Hansen 
> Acked-by: Will Deacon 
> Signed-off-by: Linus Torvalds 
>
> :04 04 a4768484a068b37a43863123ac782fb6d01149b7 
> 75ff0be6a2f3e4caa9a06df6503fa54d25dfa44d M  mm

in an aarch64 QEMU/KVM guest running Fedora 21 Server (8GB RAM, 8
VCPUs). I bisected between v3.18 and v3.19-rc3. I used
"config-3.17.4-302.fc21.aarch64" as starting config, on which I kept
running olddefconfig and localmodconfig.


It is beneficial to perform such a bisection in a virtual machine. Super
fast reboot times, and the hot parts of the virtual disk are cached in
host memory. It's easy to boot a test kernel for running the reproducer,
and then reboot the known good distro kernel for building the next step
in the bisection.


As reproducer I used "./mallocstress -t 300" (recommended by Mark
Langsdorf & Kyle McMartin, but also named by Will just above this
thread).

One thing I noticed during the several repro turns is that the OOM
killer never hit while mallocstress was running "normally" (ie. before
the first thread exited). In the broken kernels, the OOM killer always
hit after a few (tens) of the threads had exited. The leak is probably
related to thread exit. (Which is consistent with the kernel build
reproducer, because that causes a lot of threads (processes) to exit
too.)

Bisection log below.

Thanks
Laszlo

git bisect start
# bad: [b1940cd21c0f4abdce101253e860feff547291b0] Linux 3.19-rc3
git bisect bad b1940cd21c0f4abdce101253e860feff547291b0
# good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d
# good: [a7cfef21e3d066343bec14d3113a9f9c92d1c2a8] Merge branches 'core', 
'cxgb4', 'ipoib', 'iser', 'mlx4', 'ocrdma', 'odp' and 'srp' into for-next
git bisect good a7cfef21e3d066343bec14d3113a9f9c92d1c2a8
# good: 

Re: Linux 3.19-rc3

2015-01-09 Thread Tony Luck
On Fri, Jan 9, 2015 at 6:27 PM, Linus Torvalds
 wrote:
> Big pages are a bad bad bad idea. They work fine for databases, and
> that's pretty much just about it. I'm sure there are some other loads,
> but they are few and far between.

For HPC too. They tend not to do a lot of I/O (and when they do it is
from a few big files). Then they just sit crunching over gigabytes of
memory for seven and a half million years before doing:

printf("Answer is %d\n", 42);

-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: noisy selinux messages on tmpfs mount.

2015-01-09 Thread Paul Moore
systemd has taken over cron too?  I suppose that is a logical extension, 
but still...


--
paul moore
www.paul-moore.com



On January 9, 2015 4:01:29 PM Dominick Grift  wrote:


On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> >  > We already reduced that message to KERN_DEBUG.  Is that not sufficient?
> >
> > That doesn't really help with the flooding of dmesg, so no.
> > I should also note that it's not just logging in that creates a new
> > session, it also seems to be getting triggered by cron jobs, or
> > whatever the systemd replacement is.
>
> I wonder if this is cron/systemd/whatever creating a new namespace and
> mounting a new tmpfs in the namespace?  If yes, I wonder if we could 
limit the

> messages to the initial namespace ... ?
>

It is systemd logind creating sessions (e.g. creating /run/user/$UID and
mounting a tmpfs on it)




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



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

2015-01-09 Thread Linus Torvalds
On Fri, Jan 9, 2015 at 6:51 PM, David Lang  wrote:
>
> what about a dedicated virtualization host (where your workload is a handful
> of virtual machines), would the file cache issue still be overwelming, even
> though it's the virtual machines accessing things?

How much filesystem caches does the host need or use? It can range
from basically zero ("pure" hypervisor host with no filesystem at all)
to 100% (virtual filesystem in all the clients with the host doing all
the real work).

I dunno. I do know that you definitely don't want to haev a
desktop/workstation with 64kB pages.

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: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Al Viro
On Fri, Jan 09, 2015 at 11:36:44PM +, Al Viro wrote:
> On Fri, Jan 09, 2015 at 06:12:48PM -0500, Rich Felker wrote:
> 
> > I'm not sure where you're disagreeing with me. open of procfs symlinks
> > does not resolve the symlink and open the resulting pathname. They are
> > "magic symlinks" which are bound to the inode of the open file. I
> > don't see why this action, which is already special for magic
> > symlinks, can't check a flag on the magic symlink and possibly close
> > the corresponding file descriptor as part of its action.
> 
> _What_ action?  ->follow_link()?  As in "the same thing that e.g.
> stat(2) would trigger"?

To elaborate a bit: the fundamental method for symlink traversal is
->follow_link().  It gets dentry of the object itself + opaque context.
Usually it just obtains some string (== symlink contents) and calls
nd_set_link(context, string).  In that case the string will be interpreted
by its callers in usual way.  Another possibility is to call
nd_jump_link(context, location), which will reset the current position
(directory in which the symlink has been found and relative to which it
would be interpreted) to given location in tree.  It might actually do
both - then the string will be interpreted relative to the new location.
Once the pathname resolution is done with the string stored by nd_set_link(),
it calls another method - ->put_link().  That one releases the object
that contains this string; it gets an opaque pointer returned by
->follow_link().  Returning ERR_PTR(-Esomething) indicates an error, so does
nd_set_link(context, ERR_PTR(-Esomething)).

readlink(2) is using a different method (->readlink()) and any object whose
->follow_link() only uses nd_set_link() can use generic_readlink as its
->readlink instance - that will call ->follow_link(), copy the string
stored by nd_set_link() to userland buffer and use ->put_link() to release
whatever needs to be released.  Most of the symlinks are doing just that.

procfs "magical" symlinks have ->follow_link() that uses nd_jump_link();
they obviously can't use generic_readlink() (there is no string left
by ->follow_link() for caller to traverse), so they have non-standard
->readlink() instances - ones that use d_path() to generate a plausible
pathname of the would-be destination of their ->follow_link().  Or something
like pipe:[696969], etc.

Note, however, that ->readlink() is used only by readlink(2) syscall; as far
as pathname resolution is concerned it is completely irrelevant.  What matters
is ->follow_link().

Now, the callers do not know (and do not care) what a particular symlink _is_.
A symlink is just a dentry with inode that has non-NULL ->follow_link()
method.  That's it.  Moreover, _any_ pathname resolution is using the
same method for symlink traversal, be it open(2), stat(2), whatever.  If
a symlink is to be traversed, that's it - the only choice VFS has is whether
to traverse it at all or not (think of stat(2) vs lstat(2) difference, or
O_NOFOLLOW, etc.)

_After_ the traversal it's too late to do this sort of thing - after all,
how do you tell if your current position had been set by the traversal of
your symlink or that of any normal /proc/self/fd/?

And doing that _during_ the traversal would really suck - stray ls -lR /proc
could race with that open() done by script interpreter.

It might be possible to work around that, but trying that rapidly gets into
very ugly territory, *especially* since the handling of the final component
of open(2) (fs/namei.c:do_last()) is already far too convoluted.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3.19-rc3

2015-01-09 Thread David Lang

On Fri, 9 Jan 2015, Linus Torvalds wrote:


Big pages are a bad bad bad idea. They work fine for databases, and
that's pretty much just about it. I'm sure there are some other loads,
but they are few and far between.


what about a dedicated virtualization host (where your workload is a handful of 
virtual machines), would the file cache issue still be overwelming, even though 
it's the virtual machines accessing things?


David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/16] mn10300: add struct pci_ops member names to initialization

2015-01-09 Thread Rob Herring
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.

Signed-off-by: Rob Herring 
Cc: David Howells 
Cc: Koichi Yasutake 
Cc: linux-am33-l...@redhat.com
---
 arch/mn10300/unit-asb2305/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mn10300/unit-asb2305/pci.c b/arch/mn10300/unit-asb2305/pci.c
index 6b4339f..406cbe0 100644
--- a/arch/mn10300/unit-asb2305/pci.c
+++ b/arch/mn10300/unit-asb2305/pci.c
@@ -228,8 +228,8 @@ static int pci_ampci_write_config(struct pci_bus *bus, 
unsigned int devfn,
 }
 
 static struct pci_ops pci_direct_ampci = {
-   pci_ampci_read_config,
-   pci_ampci_write_config,
+   .read = pci_ampci_read_config,
+   .write = pci_ampci_write_config,
 };
 
 /*
-- 
2.1.0

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


[PATCH 01/16] frv: add struct pci_ops member names to initialization

2015-01-09 Thread Rob Herring
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.

Signed-off-by: Rob Herring 
Cc: David Howells 
---
 arch/frv/mb93090-mb00/pci-vdk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/frv/mb93090-mb00/pci-vdk.c b/arch/frv/mb93090-mb00/pci-vdk.c
index efa5d65..b073f4d 100644
--- a/arch/frv/mb93090-mb00/pci-vdk.c
+++ b/arch/frv/mb93090-mb00/pci-vdk.c
@@ -168,8 +168,8 @@ static int pci_frv_write_config(struct pci_bus *bus, 
unsigned int devfn, int whe
 }
 
 static struct pci_ops pci_direct_frv = {
-   pci_frv_read_config,
-   pci_frv_write_config,
+   .read = pci_frv_read_config,
+   .write = pci_frv_write_config,
 };
 
 /*
-- 
2.1.0

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


[PATCH 05/16] pci: introduce common pci config space accessors

2015-01-09 Thread Rob Herring
Many PCI controllers' configuration space accesses are memory mapped
varying only in address calculation and access checks. There are 2 main
access methods: a decoded address space such as ECAM or a single address
and data register similar to x86. This implementation can support both
cases as well as be used in cases that need additional pre or post access
handling.

A new pci_ops member map_bus is introduced which can do access checks and
any necessary setup. It returns the address to use for the configuration
space access. The access types supported are 32-bit only accesses or
correct byte, word, or dword sized accesses.

Signed-off-by: Rob Herring 
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
---
 drivers/pci/access.c | 87 
 include/linux/pci.h  | 11 +++
 2 files changed, 98 insertions(+)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 49dd766..d9b64a1 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -67,6 +67,93 @@ EXPORT_SYMBOL(pci_bus_write_config_byte);
 EXPORT_SYMBOL(pci_bus_write_config_word);
 EXPORT_SYMBOL(pci_bus_write_config_dword);
 
+int pci_generic_config_read(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 *val)
+{
+   void __iomem *addr;
+
+   addr = bus->ops->map_bus(bus, devfn, where);
+   if (!addr) {
+   *val = ~0;
+   return PCIBIOS_DEVICE_NOT_FOUND;
+   }
+
+   if (size == 1)
+   *val = readb(addr);
+   else if (size == 2)
+   *val = readw(addr);
+   else
+   *val = readl(addr);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+EXPORT_SYMBOL_GPL(pci_generic_config_read);
+
+int pci_generic_config_write(struct pci_bus *bus, unsigned int devfn,
+int where, int size, u32 val)
+{
+   void __iomem *addr;
+
+   addr = bus->ops->map_bus(bus, devfn, where);
+   if (!addr)
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   if (size == 1)
+   writeb(val, addr);
+   else if (size == 2)
+   writew(val, addr);
+   else
+   writel(val, addr);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+EXPORT_SYMBOL_GPL(pci_generic_config_write);
+
+int pci_generic_config_read32(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val)
+{
+   void __iomem *addr;
+
+   addr = bus->ops->map_bus(bus, devfn, where & ~0x3);
+   if (!addr) {
+   *val = ~0;
+   return PCIBIOS_DEVICE_NOT_FOUND;
+   }
+
+   *val = readl(addr);
+
+   if (size <= 2)
+   *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+EXPORT_SYMBOL_GPL(pci_generic_config_read32);
+
+int pci_generic_config_write32(struct pci_bus *bus, unsigned int devfn,
+  int where, int size, u32 val)
+{
+   void __iomem *addr;
+   u32 mask, tmp;
+
+   addr = bus->ops->map_bus(bus, devfn, where & ~0x3);
+   if (!addr)
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   if (size == 4) {
+   writel(val, addr);
+   return PCIBIOS_SUCCESSFUL;
+   } else {
+   mask = ~(((1 << (size * 8)) - 1) << ((where & 0x3) * 8));
+   }
+
+   tmp = readl(addr) & mask;
+   tmp |= val << ((where & 0x3) * 8);
+   writel(tmp, addr);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+EXPORT_SYMBOL_GPL(pci_generic_config_write32);
+
 /**
  * pci_bus_set_ops - Set raw operations of pci bus
  * @bus:   pci bus struct
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 360a966..e7fd519 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -560,6 +560,7 @@ static inline int pcibios_err_to_errno(int err)
 /* Low-level architecture-dependent routines */
 
 struct pci_ops {
+   void __iomem *(*map_bus)(struct pci_bus *bus, unsigned int devfn, int 
where);
int (*read)(struct pci_bus *bus, unsigned int devfn, int where, int 
size, u32 *val);
int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int 
size, u32 val);
 };
@@ -857,6 +858,16 @@ int pci_bus_write_config_word(struct pci_bus *bus, 
unsigned int devfn,
  int where, u16 val);
 int pci_bus_write_config_dword(struct pci_bus *bus, unsigned int devfn,
   int where, u32 val);
+
+int pci_generic_config_read(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 *val);
+int pci_generic_config_write(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 val);
+int pci_generic_config_read32(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val);
+int pci_generic_config_write32(struct pci_bus *bus, unsigned int devfn,
+  int where, int size, u32 val);
+

[PATCH 10/16] powerpc: fsl_pci: convert PCI to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the fsl_pci driver to use the generic config access functions.

This changes accesses from (in|out)_(8|le16|le32) to readX/writeX
variants. I believe these should be equivalent for PCI config space
accesses, but confirmation would be nice.

Signed-off-by: Rob Herring 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/sysdev/fsl_pci.c | 46 +++
 1 file changed, 3 insertions(+), 43 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 6455c1e..271b67e 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -645,61 +645,21 @@ mapped:
return pcie->cfg_type1 + offset;
 }
 
-static int mpc83xx_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
-   int offset, int len, u32 *val)
-{
-   void __iomem *cfg_addr;
-
-   cfg_addr = mpc83xx_pcie_remap_cfg(bus, devfn, offset);
-   if (!cfg_addr)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-
-   switch (len) {
-   case 1:
-   *val = in_8(cfg_addr);
-   break;
-   case 2:
-   *val = in_le16(cfg_addr);
-   break;
-   default:
-   *val = in_le32(cfg_addr);
-   break;
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
 static int mpc83xx_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
 int offset, int len, u32 val)
 {
struct pci_controller *hose = pci_bus_to_host(bus);
-   void __iomem *cfg_addr;
-
-   cfg_addr = mpc83xx_pcie_remap_cfg(bus, devfn, offset);
-   if (!cfg_addr)
-   return PCIBIOS_DEVICE_NOT_FOUND;
 
/* PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS */
if (offset == PCI_PRIMARY_BUS && bus->number == hose->first_busno)
val &= 0xff00;
 
-   switch (len) {
-   case 1:
-   out_8(cfg_addr, val);
-   break;
-   case 2:
-   out_le16(cfg_addr, val);
-   break;
-   default:
-   out_le32(cfg_addr, val);
-   break;
-   }
-
-   return PCIBIOS_SUCCESSFUL;
+   return pci_generic_config_write(bus, devfn, offset, len, val);
 }
 
 static struct pci_ops mpc83xx_pcie_ops = {
-   .read = mpc83xx_pcie_read_config,
+   .map_bus = mpc83xx_pcie_remap_cfg,
+   .read = pci_generic_config_read,
.write = mpc83xx_pcie_write_config,
 };
 
-- 
2.1.0

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


[PATCH 07/16] ARM: integrator: convert PCI to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the integrator PCI driver to use the generic config access
functions.

This changes accesses from __raw_readX/__raw_writeX to readX/writeX
variants. The spinlock is removed because it is unnecessary. The config
read and write functions are already protected with a spinlock and no
access can occur during the .pre_init function.

Signed-off-by: Rob Herring 
Cc: Russell King 
Cc: Linus Walleij 
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/mach-integrator/pci_v3.c | 61 ---
 1 file changed, 5 insertions(+), 56 deletions(-)

diff --git a/arch/arm/mach-integrator/pci_v3.c 
b/arch/arm/mach-integrator/pci_v3.c
index c186a17..dc7782f 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -356,7 +356,6 @@ static u64 pre_mem_pci_sz;
  *  7:2register number
  *
  */
-static DEFINE_RAW_SPINLOCK(v3_lock);
 
 #undef V3_LB_BASE_PREFETCH
 #define V3_LB_BASE_PREFETCH 0
@@ -457,67 +456,21 @@ static void v3_close_config_window(void)
 static int v3_read_config(struct pci_bus *bus, unsigned int devfn, int where,
  int size, u32 *val)
 {
-   void __iomem *addr;
-   unsigned long flags;
-   u32 v;
-
-   raw_spin_lock_irqsave(_lock, flags);
-   addr = v3_open_config_window(bus, devfn, where);
-
-   switch (size) {
-   case 1:
-   v = __raw_readb(addr);
-   break;
-
-   case 2:
-   v = __raw_readw(addr);
-   break;
-
-   default:
-   v = __raw_readl(addr);
-   break;
-   }
-
+   int ret = pci_generic_config_read(bus, devfn, where, size, val);
v3_close_config_window();
-   raw_spin_unlock_irqrestore(_lock, flags);
-
-   *val = v;
-   return PCIBIOS_SUCCESSFUL;
+   return ret;
 }
 
 static int v3_write_config(struct pci_bus *bus, unsigned int devfn, int where,
   int size, u32 val)
 {
-   void __iomem *addr;
-   unsigned long flags;
-
-   raw_spin_lock_irqsave(_lock, flags);
-   addr = v3_open_config_window(bus, devfn, where);
-
-   switch (size) {
-   case 1:
-   __raw_writeb((u8)val, addr);
-   __raw_readb(addr);
-   break;
-
-   case 2:
-   __raw_writew((u16)val, addr);
-   __raw_readw(addr);
-   break;
-
-   case 4:
-   __raw_writel(val, addr);
-   __raw_readl(addr);
-   break;
-   }
-
+   int ret = pci_generic_config_write(bus, devfn, where, size, val);
v3_close_config_window();
-   raw_spin_unlock_irqrestore(_lock, flags);
-
-   return PCIBIOS_SUCCESSFUL;
+   return ret;
 }
 
 static struct pci_ops pci_v3_ops = {
+   .map_bus = v3_open_config_window,
.read   = v3_read_config,
.write  = v3_write_config,
 };
@@ -672,8 +625,6 @@ static void __init pci_v3_preinit(void)
hook_fault_code(8, v3_pci_fault, SIGBUS, 0, "external abort on 
non-linefetch");
hook_fault_code(10, v3_pci_fault, SIGBUS, 0, "external abort on 
non-linefetch");
 
-   raw_spin_lock_irqsave(_lock, flags);
-
/*
 * Unlock V3 registers, but only if they were previously locked.
 */
@@ -736,8 +687,6 @@ static void __init pci_v3_preinit(void)
v3_writew(V3_LB_CFG, v3_readw(V3_LB_CFG) | (1 << 10));
v3_writeb(V3_LB_IMASK, 0x28);
__raw_writel(3, ap_syscon_base + INTEGRATOR_SC_PCIENABLE_OFFSET);
-
-   raw_spin_unlock_irqrestore(_lock, flags);
 }
 
 static void __init pci_v3_postinit(void)
-- 
2.1.0

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


[PATCH 11/16] powerpc: powermac: convert PCI to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the powermac PCI driver to use the generic config access functions.

This changes accesses from (in|out)_(8|le16|le32) to readX/writeX
variants. I believe these should be equivalent for PCI config space
accesses, but confirmation would be nice.

Signed-off-by: Rob Herring 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/platforms/powermac/pci.c | 209 +++---
 1 file changed, 39 insertions(+), 170 deletions(-)

diff --git a/arch/powerpc/platforms/powermac/pci.c 
b/arch/powerpc/platforms/powermac/pci.c
index 04702db..f4071a6 100644
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -133,17 +133,23 @@ static void __init fixup_bus_range(struct device_node 
*bridge)
|(((unsigned int)(off)) & 0xFCUL) \
|1UL)
 
-static volatile void __iomem *macrisc_cfg_access(struct pci_controller* hose,
-  u8 bus, u8 dev_fn, u8 offset)
+static void __iomem *macrisc_cfg_map_bus(struct pci_bus *bus,
+unsigned int dev_fn,
+int offset)
 {
unsigned int caddr;
+   struct pci_controller *hose;
 
-   if (bus == hose->first_busno) {
+   hose = pci_bus_to_host(bus);
+   if (hose == NULL)
+   return NULL;
+
+   if (bus->number == hose->first_busno) {
if (dev_fn < (11 << 3))
return NULL;
caddr = MACRISC_CFA0(dev_fn, offset);
} else
-   caddr = MACRISC_CFA1(bus, dev_fn, offset);
+   caddr = MACRISC_CFA1(bus->number, dev_fn, offset);
 
/* Uninorth will return garbage if we don't read back the value ! */
do {
@@ -154,129 +160,46 @@ static volatile void __iomem *macrisc_cfg_access(struct 
pci_controller* hose,
return hose->cfg_data + offset;
 }
 
-static int macrisc_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
-{
-   struct pci_controller *hose;
-   volatile void __iomem *addr;
-
-   hose = pci_bus_to_host(bus);
-   if (hose == NULL)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-   if (offset >= 0x100)
-   return  PCIBIOS_BAD_REGISTER_NUMBER;
-   addr = macrisc_cfg_access(hose, bus->number, devfn, offset);
-   if (!addr)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-   /*
-* Note: the caller has already checked that offset is
-* suitably aligned and that len is 1, 2 or 4.
-*/
-   switch (len) {
-   case 1:
-   *val = in_8(addr);
-   break;
-   case 2:
-   *val = in_le16(addr);
-   break;
-   default:
-   *val = in_le32(addr);
-   break;
-   }
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static int macrisc_write_config(struct pci_bus *bus, unsigned int devfn,
-  int offset, int len, u32 val)
-{
-   struct pci_controller *hose;
-   volatile void __iomem *addr;
-
-   hose = pci_bus_to_host(bus);
-   if (hose == NULL)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-   if (offset >= 0x100)
-   return  PCIBIOS_BAD_REGISTER_NUMBER;
-   addr = macrisc_cfg_access(hose, bus->number, devfn, offset);
-   if (!addr)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-   /*
-* Note: the caller has already checked that offset is
-* suitably aligned and that len is 1, 2 or 4.
-*/
-   switch (len) {
-   case 1:
-   out_8(addr, val);
-   break;
-   case 2:
-   out_le16(addr, val);
-   break;
-   default:
-   out_le32(addr, val);
-   break;
-   }
-   return PCIBIOS_SUCCESSFUL;
-}
-
 static struct pci_ops macrisc_pci_ops =
 {
-   .read = macrisc_read_config,
-   .write = macrisc_write_config,
+   .map_bus = macrisc_cfg_map_bus,
+   .read = pci_generic_config_read,
+   .write = pci_generic_config_write,
 };
 
 #ifdef CONFIG_PPC32
 /*
  * Verify that a specific (bus, dev_fn) exists on chaos
  */
-static int chaos_validate_dev(struct pci_bus *bus, int devfn, int offset)
+static void __iomem *chaos_map_bus(struct pci_bus *bus, unsigned int devfn,
+  int offset)
 {
struct device_node *np;
const u32 *vendor, *device;
 
if (offset >= 0x100)
-   return  PCIBIOS_BAD_REGISTER_NUMBER;
+   return NULL;
np = of_pci_find_child_device(bus->dev.of_node, devfn);
if (np == NULL)
-   return PCIBIOS_DEVICE_NOT_FOUND;
+   return NULL;
 
vendor = of_get_property(np, "vendor-id", NULL);
device = of_get_property(np, "device-id", NULL);
if (vendor == NULL || 

[PATCH 08/16] ARM: sa1100: convert PCI to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the sa1100 nanoengine PCI driver to use the generic config access
functions.

This changes accesses from __raw_readX/__raw_writeX to readX/writeX
variants. The spinlock is removed because it is unnecessary. The config
read and write functions are already protected with a spinlock.

Signed-off-by: Rob Herring 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/mach-sa1100/pci-nanoengine.c | 94 +++
 1 file changed, 8 insertions(+), 86 deletions(-)

diff --git a/arch/arm/mach-sa1100/pci-nanoengine.c 
b/arch/arm/mach-sa1100/pci-nanoengine.c
index b704433..d7ae8d5 100644
--- a/arch/arm/mach-sa1100/pci-nanoengine.c
+++ b/arch/arm/mach-sa1100/pci-nanoengine.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -30,97 +29,20 @@
 #include 
 #include 
 
-static DEFINE_SPINLOCK(nano_lock);
-
-static int nanoengine_get_pci_address(struct pci_bus *bus,
-   unsigned int devfn, int where, void __iomem **address)
+static void __iomem *nanoengine_pci_map_bus(struct pci_bus *bus,
+   unsigned int devfn, int where)
 {
-   int ret = PCIBIOS_DEVICE_NOT_FOUND;
-   unsigned int busnr = bus->number;
+   if (bus->number != 0 || (devfn >> 3) != 0)
+   return NULL;
 
-   *address = (void __iomem *)NANO_PCI_CONFIG_SPACE_VIRT +
+   return (void __iomem *)NANO_PCI_CONFIG_SPACE_VIRT +
((bus->number << 16) | (devfn << 8) | (where & ~3));
-
-   ret = (busnr > 255 || devfn > 255 || where > 255) ?
-   PCIBIOS_DEVICE_NOT_FOUND : PCIBIOS_SUCCESSFUL;
-
-   return ret;
-}
-
-static int nanoengine_read_config(struct pci_bus *bus, unsigned int devfn, int 
where,
-   int size, u32 *val)
-{
-   int ret;
-   void __iomem *address;
-   unsigned long flags;
-   u32 v;
-
-   /* nanoEngine PCI bridge does not return -1 for a non-existing
-* device. We must fake the answer. We know that the only valid
-* device is device zero at bus 0, which is the network chip. */
-   if (bus->number != 0 || (devfn >> 3) != 0) {
-   v = -1;
-   nanoengine_get_pci_address(bus, devfn, where, );
-   goto exit_function;
-   }
-
-   spin_lock_irqsave(_lock, flags);
-
-   ret = nanoengine_get_pci_address(bus, devfn, where, );
-   if (ret != PCIBIOS_SUCCESSFUL)
-   return ret;
-   v = __raw_readl(address);
-
-   spin_unlock_irqrestore(_lock, flags);
-
-   v >>= ((where & 3) * 8);
-   v &= (unsigned long)(-1) >> ((4 - size) * 8);
-
-exit_function:
-   *val = v;
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static int nanoengine_write_config(struct pci_bus *bus, unsigned int devfn, 
int where,
-   int size, u32 val)
-{
-   int ret;
-   void __iomem *address;
-   unsigned long flags;
-   unsigned shift;
-   u32 v;
-
-   shift = (where & 3) * 8;
-
-   spin_lock_irqsave(_lock, flags);
-
-   ret = nanoengine_get_pci_address(bus, devfn, where, );
-   if (ret != PCIBIOS_SUCCESSFUL)
-   return ret;
-   v = __raw_readl(address);
-   switch (size) {
-   case 1:
-   v &= ~(0xFF << shift);
-   v |= val << shift;
-   break;
-   case 2:
-   v &= ~(0x << shift);
-   v |= val << shift;
-   break;
-   case 4:
-   v = val;
-   break;
-   }
-   __raw_writel(v, address);
-
-   spin_unlock_irqrestore(_lock, flags);
-
-   return PCIBIOS_SUCCESSFUL;
 }
 
 static struct pci_ops pci_nano_ops = {
-   .read   = nanoengine_read_config,
-   .write  = nanoengine_write_config,
+   .map_bus = nanoengine_pci_map_bus,
+   .read   = pci_generic_config_read32,
+   .write  = pci_generic_config_write32,
 };
 
 static int __init pci_nanoengine_map_irq(const struct pci_dev *dev, u8 slot,
-- 
2.1.0

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


[PATCH 13/16] pci/host: rcar-gen2: convert to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the rcar-gen2 host PCI driver to use the generic config access
functions.

This changes the i/o accessors from io(read|write)X to readX/writeX
variants which are equivalent on ARM.

Signed-off-by: Rob Herring 
Cc: Simon Horman 
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
 drivers/pci/host/pci-rcar-gen2.c | 51 +++-
 1 file changed, 3 insertions(+), 48 deletions(-)

diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index d9c042f..dd6b84e 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -131,52 +131,6 @@ static void __iomem *rcar_pci_cfg_base(struct pci_bus 
*bus, unsigned int devfn,
return priv->reg + (slot >> 1) * 0x100 + where;
 }
 
-static int rcar_pci_read_config(struct pci_bus *bus, unsigned int devfn,
-   int where, int size, u32 *val)
-{
-   void __iomem *reg = rcar_pci_cfg_base(bus, devfn, where);
-
-   if (!reg)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-
-   switch (size) {
-   case 1:
-   *val = ioread8(reg);
-   break;
-   case 2:
-   *val = ioread16(reg);
-   break;
-   default:
-   *val = ioread32(reg);
-   break;
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static int rcar_pci_write_config(struct pci_bus *bus, unsigned int devfn,
-int where, int size, u32 val)
-{
-   void __iomem *reg = rcar_pci_cfg_base(bus, devfn, where);
-
-   if (!reg)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-
-   switch (size) {
-   case 1:
-   iowrite8(val, reg);
-   break;
-   case 2:
-   iowrite16(val, reg);
-   break;
-   default:
-   iowrite32(val, reg);
-   break;
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
 /* PCI interrupt mapping */
 static int rcar_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
@@ -325,8 +279,9 @@ static int rcar_pci_setup(int nr, struct pci_sys_data *sys)
 }
 
 static struct pci_ops rcar_pci_ops = {
-   .read   = rcar_pci_read_config,
-   .write  = rcar_pci_write_config,
+   .map_bus = rcar_pci_cfg_base,
+   .read   = pci_generic_config_read,
+   .write  = pci_generic_config_write,
 };
 
 static int rcar_pci_probe(struct platform_device *pdev)
-- 
2.1.0

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


[PATCH 14/16] pci/host: tegra: convert to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the tegra host PCI driver to use the generic config access
functions.

Signed-off-by: Rob Herring 
Cc: Thierry Reding 
Cc: Bjorn Helgaas 
Cc: Stephen Warren 
Cc: Alexandre Courbot 
Cc: linux-te...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/host/pci-tegra.c | 55 +++-
 1 file changed, 3 insertions(+), 52 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index a800ae9..44fd31b 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -480,59 +480,10 @@ static void __iomem *tegra_pcie_conf_address(struct 
pci_bus *bus,
return addr;
 }
 
-static int tegra_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
-   int where, int size, u32 *value)
-{
-   void __iomem *addr;
-
-   addr = tegra_pcie_conf_address(bus, devfn, where);
-   if (!addr) {
-   *value = 0x;
-   return PCIBIOS_DEVICE_NOT_FOUND;
-   }
-
-   *value = readl(addr);
-
-   if (size == 1)
-   *value = (*value >> (8 * (where & 3))) & 0xff;
-   else if (size == 2)
-   *value = (*value >> (8 * (where & 3))) & 0x;
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static int tegra_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
-int where, int size, u32 value)
-{
-   void __iomem *addr;
-   u32 mask, tmp;
-
-   addr = tegra_pcie_conf_address(bus, devfn, where);
-   if (!addr)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-
-   if (size == 4) {
-   writel(value, addr);
-   return PCIBIOS_SUCCESSFUL;
-   }
-
-   if (size == 2)
-   mask = ~(0x << ((where & 0x3) * 8));
-   else if (size == 1)
-   mask = ~(0xff << ((where & 0x3) * 8));
-   else
-   return PCIBIOS_BAD_REGISTER_NUMBER;
-
-   tmp = readl(addr) & mask;
-   tmp |= value << ((where & 0x3) * 8);
-   writel(tmp, addr);
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
 static struct pci_ops tegra_pcie_ops = {
-   .read = tegra_pcie_read_conf,
-   .write = tegra_pcie_write_conf,
+   .map_bus = tegra_pcie_conf_address,
+   .read = pci_generic_config_read32,
+   .write = pci_generic_config_write32,
 };
 
 static unsigned long tegra_pcie_port_get_pex_ctrl(struct tegra_pcie_port *port)
-- 
2.1.0

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


[PATCH 15/16] pci/host: xgene: convert to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the xgene host PCI driver to use the generic config access
functions.

Signed-off-by: Rob Herring 
Cc: Tanmay Inamdar 
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/pci/host/pci-xgene.c | 150 +++
 1 file changed, 9 insertions(+), 141 deletions(-)

diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index b1d0596..ee6a3d3 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -74,92 +74,6 @@ static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
return (addr & PCI_BASE_ADDRESS_MEM_MASK) | flags;
 }
 
-/* PCIe Configuration Out/In */
-static inline void xgene_pcie_cfg_out32(void __iomem *addr, int offset, u32 
val)
-{
-   writel(val, addr + offset);
-}
-
-static inline void xgene_pcie_cfg_out16(void __iomem *addr, int offset, u16 
val)
-{
-   u32 val32 = readl(addr + (offset & ~0x3));
-
-   switch (offset & 0x3) {
-   case 2:
-   val32 &= ~0x;
-   val32 |= (u32)val << 16;
-   break;
-   case 0:
-   default:
-   val32 &= ~0x;
-   val32 |= val;
-   break;
-   }
-   writel(val32, addr + (offset & ~0x3));
-}
-
-static inline void xgene_pcie_cfg_out8(void __iomem *addr, int offset, u8 val)
-{
-   u32 val32 = readl(addr + (offset & ~0x3));
-
-   switch (offset & 0x3) {
-   case 0:
-   val32 &= ~0xFF;
-   val32 |= val;
-   break;
-   case 1:
-   val32 &= ~0xFF00;
-   val32 |= (u32)val << 8;
-   break;
-   case 2:
-   val32 &= ~0xFF;
-   val32 |= (u32)val << 16;
-   break;
-   case 3:
-   default:
-   val32 &= ~0xFF00;
-   val32 |= (u32)val << 24;
-   break;
-   }
-   writel(val32, addr + (offset & ~0x3));
-}
-
-static inline void xgene_pcie_cfg_in32(void __iomem *addr, int offset, u32 
*val)
-{
-   *val = readl(addr + offset);
-}
-
-static inline void xgene_pcie_cfg_in16(void __iomem *addr, int offset, u32 
*val)
-{
-   *val = readl(addr + (offset & ~0x3));
-
-   switch (offset & 0x3) {
-   case 2:
-   *val >>= 16;
-   break;
-   }
-
-   *val &= 0x;
-}
-
-static inline void xgene_pcie_cfg_in8(void __iomem *addr, int offset, u32 *val)
-{
-   *val = readl(addr + (offset & ~0x3));
-
-   switch (offset & 0x3) {
-   case 3:
-   *val = *val >> 24;
-   break;
-   case 2:
-   *val = *val >> 16;
-   break;
-   case 1:
-   *val = *val >> 8;
-   break;
-   }
-   *val &= 0xFF;
-}
-
 /*
  * When the address bit [17:16] is 2'b01, the Configuration access will be
  * treated as Type 1 and it will be forwarded to external PCIe device.
@@ -213,69 +127,23 @@ static bool xgene_pcie_hide_rc_bars(struct pci_bus *bus, 
int offset)
return false;
 }
 
-static int xgene_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
-{
-   struct xgene_pcie_port *port = bus->sysdata;
-   void __iomem *addr;
-
-   if ((pci_is_root_bus(bus) && devfn != 0) || !port->link_up)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-
-   if (xgene_pcie_hide_rc_bars(bus, offset)) {
-   *val = 0;
-   return PCIBIOS_SUCCESSFUL;
-   }
-
-   xgene_pcie_set_rtdid_reg(bus, devfn);
-   addr = xgene_pcie_get_cfg_base(bus);
-   switch (len) {
-   case 1:
-   xgene_pcie_cfg_in8(addr, offset, val);
-   break;
-   case 2:
-   xgene_pcie_cfg_in16(addr, offset, val);
-   break;
-   default:
-   xgene_pcie_cfg_in32(addr, offset, val);
-   break;
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static int xgene_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
-  int offset, int len, u32 val)
+static int xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
+ int offset)
 {
struct xgene_pcie_port *port = bus->sysdata;
-   void __iomem *addr;
 
-   if ((pci_is_root_bus(bus) && devfn != 0) || !port->link_up)
-   return PCIBIOS_DEVICE_NOT_FOUND;
-
-   if (xgene_pcie_hide_rc_bars(bus, offset))
-   return PCIBIOS_SUCCESSFUL;
+   if ((pci_is_root_bus(bus) && devfn != 0) || !port->link_up ||
+   xgene_pcie_hide_rc_bars(bus, offset))
+   return NULL;
 
xgene_pcie_set_rtdid_reg(bus, devfn);
-   addr = xgene_pcie_get_cfg_base(bus);
-   switch (len) {
-   case 1:
-   xgene_pcie_cfg_out8(addr, offset, (u8)val);
-   break;
-   case 2:
-   xgene_pcie_cfg_out16(addr, 

[PATCH 12/16] pci/host: generic: convert to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the generic host PCI driver to use the generic config access
functions.

Signed-off-by: Rob Herring 
Cc: Will Deacon 
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/pci/host/pci-host-generic.c | 51 +++--
 1 file changed, 3 insertions(+), 48 deletions(-)

diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index 6eb1aa7..925e29e 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -76,55 +76,9 @@ static struct gen_pci_cfg_bus_ops gen_pci_cfg_ecam_bus_ops = 
{
.map_bus= gen_pci_map_cfg_bus_ecam,
 };
 
-static int gen_pci_config_read(struct pci_bus *bus, unsigned int devfn,
-   int where, int size, u32 *val)
-{
-   void __iomem *addr;
-   struct pci_sys_data *sys = bus->sysdata;
-   struct gen_pci *pci = sys->private_data;
-
-   addr = pci->cfg.ops->map_bus(bus, devfn, where);
-
-   switch (size) {
-   case 1:
-   *val = readb(addr);
-   break;
-   case 2:
-   *val = readw(addr);
-   break;
-   default:
-   *val = readl(addr);
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static int gen_pci_config_write(struct pci_bus *bus, unsigned int devfn,
-int where, int size, u32 val)
-{
-   void __iomem *addr;
-   struct pci_sys_data *sys = bus->sysdata;
-   struct gen_pci *pci = sys->private_data;
-
-   addr = pci->cfg.ops->map_bus(bus, devfn, where);
-
-   switch (size) {
-   case 1:
-   writeb(val, addr);
-   break;
-   case 2:
-   writew(val, addr);
-   break;
-   default:
-   writel(val, addr);
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
 static struct pci_ops gen_pci_ops = {
-   .read   = gen_pci_config_read,
-   .write  = gen_pci_config_write,
+   .read   = pci_generic_config_read,
+   .write  = pci_generic_config_write,
 };
 
 static const struct of_device_id gen_pci_of_match[] = {
@@ -287,6 +241,7 @@ static int gen_pci_probe(struct platform_device *pdev)
 
of_id = of_match_node(gen_pci_of_match, np);
pci->cfg.ops = of_id->data;
+   gen_pci_ops.map_bus = pci->cfg.ops->map_bus;
pci->host.dev.parent = dev;
INIT_LIST_HEAD(>host.windows);
INIT_LIST_HEAD(>resources);
-- 
2.1.0

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


[PATCH 16/16] pci/host: xilinx: convert to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the Xilinx host PCI driver to use the generic config access
functions.

Signed-off-by: Rob Herring 
Cc: Bjorn Helgaas 
Cc: Michal Simek 
Cc: "Sören Brinkmann" 
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/pci/host/pcie-xilinx.c | 88 +-
 1 file changed, 9 insertions(+), 79 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index ef3ebaf..f67d036 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -189,7 +189,7 @@ static bool xilinx_pcie_valid_device(struct pci_bus *bus, 
unsigned int devfn)
 }
 
 /**
- * xilinx_pcie_config_base - Get configuration base
+ * xilinx_pcie_map_bus - Get configuration base
  * @bus: PCI Bus structure
  * @devfn: Device/function
  * @where: Offset from base
@@ -197,96 +197,26 @@ static bool xilinx_pcie_valid_device(struct pci_bus *bus, 
unsigned int devfn)
  * Return: Base address of the configuration space needed to be
  *accessed.
  */
-static void __iomem *xilinx_pcie_config_base(struct pci_bus *bus,
-unsigned int devfn, int where)
+static void __iomem *xilinx_pcie_map_bus(struct pci_bus *bus,
+unsigned int devfn, int where)
 {
struct xilinx_pcie_port *port = sys_to_pcie(bus->sysdata);
int relbus;
 
+   if (!xilinx_pcie_valid_device(bus, devfn))
+   return NULL;
+
relbus = (bus->number << ECAM_BUS_NUM_SHIFT) |
 (devfn << ECAM_DEV_NUM_SHIFT);
 
return port->reg_base + relbus + where;
 }
 
-/**
- * xilinx_pcie_read_config - Read configuration space
- * @bus: PCI Bus structure
- * @devfn: Device/function
- * @where: Offset from base
- * @size: Byte/word/dword
- * @val: Value to be read
- *
- * Return: PCIBIOS_SUCCESSFUL on success
- *PCIBIOS_DEVICE_NOT_FOUND on failure
- */
-static int xilinx_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
-  int where, int size, u32 *val)
-{
-   void __iomem *addr;
-
-   if (!xilinx_pcie_valid_device(bus, devfn)) {
-   *val = 0x;
-   return PCIBIOS_DEVICE_NOT_FOUND;
-   }
-
-   addr = xilinx_pcie_config_base(bus, devfn, where);
-
-   switch (size) {
-   case 1:
-   *val = readb(addr);
-   break;
-   case 2:
-   *val = readw(addr);
-   break;
-   default:
-   *val = readl(addr);
-   break;
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
-/**
- * xilinx_pcie_write_config - Write configuration space
- * @bus: PCI Bus structure
- * @devfn: Device/function
- * @where: Offset from base
- * @size: Byte/word/dword
- * @val: Value to be written to device
- *
- * Return: PCIBIOS_SUCCESSFUL on success
- *PCIBIOS_DEVICE_NOT_FOUND on failure
- */
-static int xilinx_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
-   int where, int size, u32 val)
-{
-   void __iomem *addr;
-
-   if (!xilinx_pcie_valid_device(bus, devfn))
-   return PCIBIOS_DEVICE_NOT_FOUND;
-
-   addr = xilinx_pcie_config_base(bus, devfn, where);
-
-   switch (size) {
-   case 1:
-   writeb(val, addr);
-   break;
-   case 2:
-   writew(val, addr);
-   break;
-   default:
-   writel(val, addr);
-   break;
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
 /* PCIe operations */
 static struct pci_ops xilinx_pcie_ops = {
-   .read  = xilinx_pcie_read_config,
-   .write = xilinx_pcie_write_config,
+   .map_bus = xilinx_pcie_map_bus,
+   .read   = pci_generic_config_read,
+   .write  = pci_generic_config_write,
 };
 
 /* MSI functions */
-- 
2.1.0

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


[PATCH 09/16] ARM: ks8695: convert PCI to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the ks8695 PCI driver to use the generic config access functions.

This changes accesses from __raw_readX/__raw_writeX to readX/writeX
variants.

Signed-off-by: Rob Herring 
Cc: Greg Ungerer 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/mach-ks8695/pci.c | 77 --
 1 file changed, 6 insertions(+), 71 deletions(-)

diff --git a/arch/arm/mach-ks8695/pci.c b/arch/arm/mach-ks8695/pci.c
index bb18193..c1bc4c3 100644
--- a/arch/arm/mach-ks8695/pci.c
+++ b/arch/arm/mach-ks8695/pci.c
@@ -38,8 +38,6 @@
 
 
 static int pci_dbg;
-static int pci_cfg_dbg;
-
 
 static void ks8695_pci_setupconfig(unsigned int bus_nr, unsigned int devfn, 
unsigned int where)
 {
@@ -59,75 +57,11 @@ static void ks8695_pci_setupconfig(unsigned int bus_nr, 
unsigned int devfn, unsi
}
 }
 
-
-/*
- * The KS8695 datasheet prohibits anything other than 32bit accesses
- * to the IO registers, so all our configuration must be done with
- * 32bit operations, and the correct bit masking and shifting.
- */
-
-static int ks8695_pci_readconfig(struct pci_bus *bus,
-   unsigned int devfn, int where, int size, u32 *value)
-{
-   ks8695_pci_setupconfig(bus->number, devfn, where);
-
-   *value = __raw_readl(KS8695_PCI_VA +  KS8695_PBCD);
-
-   switch (size) {
-   case 4:
-   break;
-   case 2:
-   *value = *value >> ((where & 2) * 8);
-   *value &= 0x;
-   break;
-   case 1:
-   *value = *value >> ((where & 3) * 8);
-   *value &= 0xff;
-   break;
-   }
-
-   if (pci_cfg_dbg) {
-   printk("read: %d,%08x,%02x,%d: %08x (%08x)\n",
-   bus->number, devfn, where, size, *value,
-   __raw_readl(KS8695_PCI_VA +  KS8695_PBCD));
-   }
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static int ks8695_pci_writeconfig(struct pci_bus *bus,
-   unsigned int devfn, int where, int size, u32 value)
+static void __iomem *ks8695_pci_map_bus(struct pci_bus *bus, unsigned int 
devfn,
+   int where)
 {
-   unsigned long tmp;
-
-   if (pci_cfg_dbg) {
-   printk("write: %d,%08x,%02x,%d: %08x\n",
-   bus->number, devfn, where, size, value);
-   }
-
ks8695_pci_setupconfig(bus->number, devfn, where);
-
-   switch (size) {
-   case 4:
-   __raw_writel(value, KS8695_PCI_VA +  KS8695_PBCD);
-   break;
-   case 2:
-   tmp = __raw_readl(KS8695_PCI_VA +  KS8695_PBCD);
-   tmp &= ~(0x << ((where & 2) * 8));
-   tmp |= value << ((where & 2) * 8);
-
-   __raw_writel(tmp, KS8695_PCI_VA +  KS8695_PBCD);
-   break;
-   case 1:
-   tmp = __raw_readl(KS8695_PCI_VA +  KS8695_PBCD);
-   tmp &= ~(0xff << ((where & 3) * 8));
-   tmp |= value << ((where & 3) * 8);
-
-   __raw_writel(tmp, KS8695_PCI_VA +  KS8695_PBCD);
-   break;
-   }
-
-   return PCIBIOS_SUCCESSFUL;
+   return KS8695_PCI_VA +  KS8695_PBCD;
 }
 
 static void ks8695_local_writeconfig(int where, u32 value)
@@ -137,8 +71,9 @@ static void ks8695_local_writeconfig(int where, u32 value)
 }
 
 static struct pci_ops ks8695_pci_ops = {
-   .read   = ks8695_pci_readconfig,
-   .write  = ks8695_pci_writeconfig,
+   .map_bus = ks8695_pci_map_bus,
+   .read   = pci_generic_config_read32,
+   .write  = pci_generic_config_write32,
 };
 
 static struct resource pci_mem = {
-- 
2.1.0

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


[PATCH 02/16] mips: add struct pci_ops member names to initialization

2015-01-09 Thread Rob Herring
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.

Signed-off-by: Rob Herring 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
---
 arch/mips/pci/pci-bcm1480.c |  4 ++--
 arch/mips/pci/pci-octeon.c  |  4 ++--
 arch/mips/pci/pcie-octeon.c | 12 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/mips/pci/pci-bcm1480.c b/arch/mips/pci/pci-bcm1480.c
index 5ec2a7b..f2355e3 100644
--- a/arch/mips/pci/pci-bcm1480.c
+++ b/arch/mips/pci/pci-bcm1480.c
@@ -173,8 +173,8 @@ static int bcm1480_pcibios_write(struct pci_bus *bus, 
unsigned int devfn,
 }
 
 struct pci_ops bcm1480_pci_ops = {
-   bcm1480_pcibios_read,
-   bcm1480_pcibios_write,
+   .read = bcm1480_pcibios_read,
+   .write = bcm1480_pcibios_write,
 };
 
 static struct resource bcm1480_mem_resource = {
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index d07e041..bedb72b 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips/pci/pci-octeon.c
@@ -327,8 +327,8 @@ static int octeon_write_config(struct pci_bus *bus, 
unsigned int devfn,
 
 
 static struct pci_ops octeon_pci_ops = {
-   octeon_read_config,
-   octeon_write_config,
+   .read = octeon_read_config,
+   .write = octeon_write_config,
 };
 
 static struct resource octeon_pci_mem_resource = {
diff --git a/arch/mips/pci/pcie-octeon.c b/arch/mips/pci/pcie-octeon.c
index 5e36c33..eb4a17b 100644
--- a/arch/mips/pci/pcie-octeon.c
+++ b/arch/mips/pci/pcie-octeon.c
@@ -1792,8 +1792,8 @@ static int octeon_dummy_write_config(struct pci_bus *bus, 
unsigned int devfn,
 }
 
 static struct pci_ops octeon_pcie0_ops = {
-   octeon_pcie0_read_config,
-   octeon_pcie0_write_config,
+   .read = octeon_pcie0_read_config,
+   .write = octeon_pcie0_write_config,
 };
 
 static struct resource octeon_pcie0_mem_resource = {
@@ -1813,8 +1813,8 @@ static struct pci_controller octeon_pcie0_controller = {
 };
 
 static struct pci_ops octeon_pcie1_ops = {
-   octeon_pcie1_read_config,
-   octeon_pcie1_write_config,
+   .read = octeon_pcie1_read_config,
+   .write = octeon_pcie1_write_config,
 };
 
 static struct resource octeon_pcie1_mem_resource = {
@@ -1834,8 +1834,8 @@ static struct pci_controller octeon_pcie1_controller = {
 };
 
 static struct pci_ops octeon_dummy_ops = {
-   octeon_dummy_read_config,
-   octeon_dummy_write_config,
+   .read = octeon_dummy_read_config,
+   .write = octeon_dummy_write_config,
 };
 
 static struct resource octeon_dummy_mem_resource = {
-- 
2.1.0

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


[PATCH 00/16] PCI generic configuration space accessors

2015-01-09 Thread Rob Herring
This series adds common accessor functions for PCI configuration space
accesses. This supports most PCI hosts with memory mapped configuration
space like ECAM or hosts with memory mapped address/data registers. ECAM
is not generically supported by this series, but could be added on top
of this. While some hosts have standard address decoding which could be 
common as well, the various checks on bus numbers and device numbers are 
quite varied. It is unclear how much of that is really necessary or 
could be common. 

The first 4 patches are preparatory cleanup. Patch 5 introduces the
common accessors. The remaining patches convert several PCI host
controllers. This is in no way a complete list of host controllers. The
conversion of more hosts should be possible. The Designware controller
in particular should be able to be converted, but its config space
accessors are a mess of override-able functions that I've not gotten my
head around.

This series is available here [1].

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git 
pci-config-access

Rob Herring (16):
  frv: add struct pci_ops member names to initialization
  mips: add struct pci_ops member names to initialization
  mn10300: add struct pci_ops member names to initialization
  powerpc: add struct pci_ops member names to initialization
  pci: introduce common pci config space accessors
  ARM: cns3xxx: convert PCI to use generic config accesses
  ARM: integrator: convert PCI to use generic config accesses
  ARM: sa1100: convert PCI to use generic config accesses
  ARM: ks8695: convert PCI to use generic config accesses
  powerpc: fsl_pci: convert PCI to use generic config accesses
  powerpc: powermac: convert PCI to use generic config accesses
  pci/host: generic: convert to use generic config accesses
  pci/host: rcar-gen2: convert to use generic config accesses
  pci/host: tegra: convert to use generic config accesses
  pci/host: xgene: convert to use generic config accesses
  pci/host: xilinx: convert to use generic config accesses

 arch/arm/mach-cns3xxx/pcie.c   |  52 ++
 arch/arm/mach-integrator/pci_v3.c  |  61 +---
 arch/arm/mach-ks8695/pci.c |  77 +
 arch/arm/mach-sa1100/pci-nanoengine.c  |  94 +--
 arch/frv/mb93090-mb00/pci-vdk.c|   4 +-
 arch/mips/pci/pci-bcm1480.c|   4 +-
 arch/mips/pci/pci-octeon.c |   4 +-
 arch/mips/pci/pcie-octeon.c|  12 +-
 arch/mn10300/unit-asb2305/pci.c|   4 +-
 arch/powerpc/platforms/cell/celleb_scc_pciex.c |   4 +-
 arch/powerpc/platforms/powermac/pci.c  | 209 +
 arch/powerpc/sysdev/fsl_pci.c  |  46 +-
 drivers/pci/access.c   |  87 ++
 drivers/pci/host/pci-host-generic.c|  51 +-
 drivers/pci/host/pci-rcar-gen2.c   |  51 +-
 drivers/pci/host/pci-tegra.c   |  55 +--
 drivers/pci/host/pci-xgene.c   | 150 ++
 drivers/pci/host/pcie-xilinx.c |  88 ++-
 include/linux/pci.h|  11 ++
 19 files changed, 212 insertions(+), 852 deletions(-)

-- 
2.1.0

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


[PATCH 04/16] powerpc: add struct pci_ops member names to initialization

2015-01-09 Thread Rob Herring
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.

Signed-off-by: Rob Herring 
Cc: Arnd Bergmann 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-...@lists.ozlabs.org
Cc: cbe-oss-...@lists.ozlabs.org
---
 arch/powerpc/platforms/cell/celleb_scc_pciex.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/cell/celleb_scc_pciex.c 
b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
index f223875..94170e4 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
@@ -399,8 +399,8 @@ static int scc_pciex_write_config(struct pci_bus *bus, 
unsigned int devfn,
 }
 
 static struct pci_ops scc_pciex_pci_ops = {
-   scc_pciex_read_config,
-   scc_pciex_write_config,
+   .read = scc_pciex_read_config,
+   .write = scc_pciex_write_config,
 };
 
 static void pciex_clear_intr_all(unsigned int __iomem *base)
-- 
2.1.0

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


[PATCH 06/16] ARM: cns3xxx: convert PCI to use generic config accesses

2015-01-09 Thread Rob Herring
Convert the cns3xxx PCI driver to use the generic config access functions.

This changes accesses from __raw_readl/__raw_writel to readl/writel.

Signed-off-by: Rob Herring 
Cc: Krzysztof Halasa 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/mach-cns3xxx/pcie.c | 52 +---
 1 file changed, 10 insertions(+), 42 deletions(-)

diff --git a/arch/arm/mach-cns3xxx/pcie.c b/arch/arm/mach-cns3xxx/pcie.c
index 45d6bd0..19b4e20 100644
--- a/arch/arm/mach-cns3xxx/pcie.c
+++ b/arch/arm/mach-cns3xxx/pcie.c
@@ -54,8 +54,8 @@ static struct cns3xxx_pcie *pbus_to_cnspci(struct pci_bus 
*bus)
return sysdata_to_cnspci(bus->sysdata);
 }
 
-static void __iomem *cns3xxx_pci_cfg_base(struct pci_bus *bus,
- unsigned int devfn, int where)
+static void __iomem *cns3xxx_pci_map_bus(struct pci_bus *bus,
+unsigned int devfn, int where)
 {
struct cns3xxx_pcie *cnspci = pbus_to_cnspci(bus);
int busno = bus->number;
@@ -91,55 +91,22 @@ static void __iomem *cns3xxx_pci_cfg_base(struct pci_bus 
*bus,
 static int cns3xxx_pci_read_config(struct pci_bus *bus, unsigned int devfn,
   int where, int size, u32 *val)
 {
-   u32 v;
-   void __iomem *base;
+   int ret;
u32 mask = (0x1ull << (size * 8)) - 1;
int shift = (where % 4) * 8;
 
-   base = cns3xxx_pci_cfg_base(bus, devfn, where);
-   if (!base) {
-   *val = 0x;
-   return PCIBIOS_SUCCESSFUL;
-   }
-
-   v = __raw_readl(base);
+   ret = pci_generic_config_read32(bus, devfn, where, size, val);
 
-   if (bus->number == 0 && devfn == 0 &&
-   (where & 0xffc) == PCI_CLASS_REVISION) {
+   if (ret == PCIBIOS_SUCCESSFUL && !bus->number && !devfn &&
+   (where & 0xffc) == PCI_CLASS_REVISION)
/*
 * RC's class is 0xb, but Linux PCI driver needs 0x604
 * for a PCIe bridge. So we must fixup the class code
 * to 0x604 here.
 */
-   v &= 0xff;
-   v |= 0x604 << 16;
-   }
-
-   *val = (v >> shift) & mask;
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static int cns3xxx_pci_write_config(struct pci_bus *bus, unsigned int devfn,
-   int where, int size, u32 val)
-{
-   u32 v;
-   void __iomem *base;
-   u32 mask = (0x1ull << (size * 8)) - 1;
-   int shift = (where % 4) * 8;
-
-   base = cns3xxx_pci_cfg_base(bus, devfn, where);
-   if (!base)
-   return PCIBIOS_SUCCESSFUL;
-
-   v = __raw_readl(base);
-
-   v &= ~(mask << shift);
-   v |= (val & mask) << shift;
-
-   __raw_writel(v, base);
+   *val = (*val << shift) & 0xff) | (0x604 << 16)) >> shift) & 
mask;
 
-   return PCIBIOS_SUCCESSFUL;
+   return ret;
 }
 
 static int cns3xxx_pci_setup(int nr, struct pci_sys_data *sys)
@@ -158,8 +125,9 @@ static int cns3xxx_pci_setup(int nr, struct pci_sys_data 
*sys)
 }
 
 static struct pci_ops cns3xxx_pcie_ops = {
+   .map_bus = cns3xxx_pci_map_bus,
.read = cns3xxx_pci_read_config,
-   .write = cns3xxx_pci_write_config,
+   .write = pci_generic_config_write,
 };
 
 static int cns3xxx_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-- 
2.1.0

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


Re: Linux 3.19-rc3

2015-01-09 Thread Linus Torvalds
On Fri, Jan 9, 2015 at 4:35 PM, Kirill A. Shutemov  wrote:
>
> With bigger page size there's also reduction in number of entities to
> handle by kernel: less memory occupied by struct pages, fewer pages on
> lru, etc.

Bah. Humbug. You've been listening to HW people too much, but they see
the small details, not the big picture.

Page management was indeed a huge PITA for PAE. But that was because
PAE is garbage.

Really, do the math. 64kB pages waste so much memory due to internal
fragmentation that any other memory use is completely immaterial.

Pretty much the only situation where 64kB pages are fine is when you
have one single meaningful load running on your machine, and that one
single load is likely a database.

Any other time, your filesystem caches will just suck.

Just as an example, look at the kernel tree. Last I did the math
(which is admittedly a long time ago), the median size (not average -
median) of a file was pretty much 4kB.

With a 64kB page, that means that for caching the kernel tree (what,
closer to 50k files by now), you are basically wasting 60kB for most
source files. Say, 60kB * 30k files, or 1.8GB.

Read that again. 1.8 GIGABYTES. Wasted. Completely unused. Thrown
away, with no upside. And that's just from the page cache for the
kernel sources, which would be populated by a single "git grep".

Maybe things have changed, and maybe I did my math wrong, and people
can give a more exact number. But it's an example of why 64kB
granularity is completely unacceptable in any kind of general-purpose
load.

Anybody who brings up TLB costs or costs of maintaining pages is just
jying, or hasn't actually looked at the real issues. Anything you win
in TLB you lose is *lots* and lots of extra IO, because you aren't
using your memory efficiently for caching, and are basically easily
throwing away half your RAM.

Big pages are a bad bad bad idea. They work fine for databases, and
that's pretty much just about it. I'm sure there are some other loads,
but they are few and far between.

4kB works well. 8kB is perfectly acceptable. 16kB is already wasting a
lot of memory. 32kB and up is complete garbage for general-purpose
computing.

And no, source code isn't *that* special. There are lots of other
cases where you have a multitude of small files. And small files are
the things you want to cache - don't tell me about big video files etc
that make a 64kB page size look small, because those files don't
actually tend to be all that relevant for caching.

   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] MAINTAINERS: add git url entry for UIO

2015-01-09 Thread Joe Perches
On Fri, 2015-01-09 at 18:13 -0800, Mandeep Sandhu wrote:
> Added git url for UIO section.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -10149,6 +10149,7 @@ S:Maintained
>  F:   Documentation/DocBook/uio-howto.tmpl
>  F:   drivers/uio/
>  F:   include/linux/uio*.h
> +T:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git

Please add a "git" prefix type and move
this line before the F: entries.

T:  git git://git.kernel.org/etc...


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [LKP] [mm] c8c06efa8b5: -7.6% unixbench.score

2015-01-09 Thread Davidlohr Bueso
I was finally able to reproduce this (had to hack the damn Run script).
I'll look into it more carefully now, thanks for reporting it.


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


[patch 1/3] mm: memcontrol: remove unnecessary soft limit tree node test

2015-01-09 Thread Johannes Weiner
kzalloc_node() automatically falls back to nodes with suitable memory.

Signed-off-by: Johannes Weiner 
---
 mm/memcontrol.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index fd9e542fc26f..aad254b30708 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4520,13 +4520,10 @@ static void __init mem_cgroup_soft_limit_tree_init(void)
 {
struct mem_cgroup_tree_per_node *rtpn;
struct mem_cgroup_tree_per_zone *rtpz;
-   int tmp, node, zone;
+   int node, zone;
 
for_each_node(node) {
-   tmp = node;
-   if (!node_state(node, N_NORMAL_MEMORY))
-   tmp = -1;
-   rtpn = kzalloc_node(sizeof(*rtpn), GFP_KERNEL, tmp);
+   rtpn = kzalloc_node(sizeof(*rtpn), GFP_KERNEL, node);
BUG_ON(!rtpn);
 
soft_limit_tree.rb_tree_per_node[node] = rtpn;
-- 
2.2.0

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


[patch 3/3] mm: memcontrol: consolidate swap controller code

2015-01-09 Thread Johannes Weiner
The swap controller code is scattered all over the file.  Gather all
the code that isn't directly needed by the memory controller at the
end of the file in its own CONFIG_MEMCG_SWAP section.

Signed-off-by: Johannes Weiner 
---
 mm/memcontrol.c | 264 +++-
 1 file changed, 125 insertions(+), 139 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f66bb8f83ac9..5a5769e8b12c 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -72,22 +72,13 @@ EXPORT_SYMBOL(memory_cgrp_subsys);
 #define MEM_CGROUP_RECLAIM_RETRIES 5
 static struct mem_cgroup *root_mem_cgroup __read_mostly;
 
+/* Whether the swap controller is active */
 #ifdef CONFIG_MEMCG_SWAP
-/* Turned on only when memory cgroup is enabled && really_do_swap_account = 1 
*/
 int do_swap_account __read_mostly;
-
-/* for remember boot option*/
-#ifdef CONFIG_MEMCG_SWAP_ENABLED
-static int really_do_swap_account __initdata = 1;
-#else
-static int really_do_swap_account __initdata;
-#endif
-
 #else
 #define do_swap_account0
 #endif
 
-
 static const char * const mem_cgroup_stat_names[] = {
"cache",
"rss",
@@ -4382,34 +4373,6 @@ static struct cftype mem_cgroup_legacy_files[] = {
{ },/* terminate */
 };
 
-#ifdef CONFIG_MEMCG_SWAP
-static struct cftype memsw_cgroup_files[] = {
-   {
-   .name = "memsw.usage_in_bytes",
-   .private = MEMFILE_PRIVATE(_MEMSWAP, RES_USAGE),
-   .read_u64 = mem_cgroup_read_u64,
-   },
-   {
-   .name = "memsw.max_usage_in_bytes",
-   .private = MEMFILE_PRIVATE(_MEMSWAP, RES_MAX_USAGE),
-   .write = mem_cgroup_reset,
-   .read_u64 = mem_cgroup_read_u64,
-   },
-   {
-   .name = "memsw.limit_in_bytes",
-   .private = MEMFILE_PRIVATE(_MEMSWAP, RES_LIMIT),
-   .write = mem_cgroup_write,
-   .read_u64 = mem_cgroup_read_u64,
-   },
-   {
-   .name = "memsw.failcnt",
-   .private = MEMFILE_PRIVATE(_MEMSWAP, RES_FAILCNT),
-   .write = mem_cgroup_reset,
-   .read_u64 = mem_cgroup_read_u64,
-   },
-   { },/* terminate */
-};
-#endif
 static int alloc_mem_cgroup_per_zone_info(struct mem_cgroup *memcg, int node)
 {
struct mem_cgroup_per_node *pn;
@@ -5415,37 +5378,6 @@ struct cgroup_subsys memory_cgrp_subsys = {
.early_init = 0,
 };
 
-#ifdef CONFIG_MEMCG_SWAP
-static int __init enable_swap_account(char *s)
-{
-   if (!strcmp(s, "1"))
-   really_do_swap_account = 1;
-   else if (!strcmp(s, "0"))
-   really_do_swap_account = 0;
-   return 1;
-}
-__setup("swapaccount=", enable_swap_account);
-
-static void __init memsw_file_init(void)
-{
-   WARN_ON(cgroup_add_legacy_cftypes(_cgrp_subsys,
- memsw_cgroup_files));
-}
-
-static void __init enable_swap_cgroup(void)
-{
-   if (!mem_cgroup_disabled() && really_do_swap_account) {
-   do_swap_account = 1;
-   memsw_file_init();
-   }
-}
-
-#else
-static void __init enable_swap_cgroup(void)
-{
-}
-#endif
-
 /**
  * mem_cgroup_events - count memory events against a cgroup
  * @memcg: the memory cgroup
@@ -5496,74 +5428,6 @@ bool mem_cgroup_low(struct mem_cgroup *root, struct 
mem_cgroup *memcg)
return true;
 }
 
-#ifdef CONFIG_MEMCG_SWAP
-/**
- * mem_cgroup_swapout - transfer a memsw charge to swap
- * @page: page whose memsw charge to transfer
- * @entry: swap entry to move the charge to
- *
- * Transfer the memsw charge of @page to @entry.
- */
-void mem_cgroup_swapout(struct page *page, swp_entry_t entry)
-{
-   struct mem_cgroup *memcg;
-   unsigned short oldid;
-
-   VM_BUG_ON_PAGE(PageLRU(page), page);
-   VM_BUG_ON_PAGE(page_count(page), page);
-
-   if (!do_swap_account)
-   return;
-
-   memcg = page->mem_cgroup;
-
-   /* Readahead page, never charged */
-   if (!memcg)
-   return;
-
-   oldid = swap_cgroup_record(entry, mem_cgroup_id(memcg));
-   VM_BUG_ON_PAGE(oldid, page);
-   mem_cgroup_swap_statistics(memcg, true);
-
-   page->mem_cgroup = NULL;
-
-   if (!mem_cgroup_is_root(memcg))
-   page_counter_uncharge(>memory, 1);
-
-   /* XXX: caller holds IRQ-safe mapping->tree_lock */
-   VM_BUG_ON(!irqs_disabled());
-
-   mem_cgroup_charge_statistics(memcg, page, -1);
-   memcg_check_events(memcg, page);
-}
-
-/**
- * mem_cgroup_uncharge_swap - uncharge a swap entry
- * @entry: swap entry to uncharge
- *
- * Drop the memsw charge associated with @entry.
- */
-void mem_cgroup_uncharge_swap(swp_entry_t entry)
-{
-   struct mem_cgroup *memcg;
-   unsigned short id;
-
-   if (!do_swap_account)
-   return;
-
-   id = swap_cgroup_record(entry, 0);
-   rcu_read_lock();
-   memcg = mem_cgroup_lookup(id);
-   

[patch 2/3] mm: memcontrol: consolidate memory controller initialization

2015-01-09 Thread Johannes Weiner
The initialization code for the per-cpu charge stock and the soft
limit tree is compact enough to inline it into mem_cgroup_init().

Signed-off-by: Johannes Weiner 
---
 mm/memcontrol.c | 57 -
 1 file changed, 24 insertions(+), 33 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index aad254b30708..f66bb8f83ac9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2137,17 +2137,6 @@ static void drain_local_stock(struct work_struct *dummy)
clear_bit(FLUSHING_CACHED_CHARGE, >flags);
 }
 
-static void __init memcg_stock_init(void)
-{
-   int cpu;
-
-   for_each_possible_cpu(cpu) {
-   struct memcg_stock_pcp *stock =
-   _cpu(memcg_stock, cpu);
-   INIT_WORK(>work, drain_local_stock);
-   }
-}
-
 /*
  * Cache charges(val) to local per_cpu area.
  * This will be consumed by consume_stock() function, later.
@@ -4516,26 +4505,6 @@ struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup 
*memcg)
 }
 EXPORT_SYMBOL(parent_mem_cgroup);
 
-static void __init mem_cgroup_soft_limit_tree_init(void)
-{
-   struct mem_cgroup_tree_per_node *rtpn;
-   struct mem_cgroup_tree_per_zone *rtpz;
-   int node, zone;
-
-   for_each_node(node) {
-   rtpn = kzalloc_node(sizeof(*rtpn), GFP_KERNEL, node);
-   BUG_ON(!rtpn);
-
-   soft_limit_tree.rb_tree_per_node[node] = rtpn;
-
-   for (zone = 0; zone < MAX_NR_ZONES; zone++) {
-   rtpz = >rb_tree_per_zone[zone];
-   rtpz->rb_root = RB_ROOT;
-   spin_lock_init(>lock);
-   }
-   }
-}
-
 static struct cgroup_subsys_state * __ref
 mem_cgroup_css_alloc(struct cgroup_subsys_state *parent_css)
 {
@@ -5927,10 +5896,32 @@ void mem_cgroup_migrate(struct page *oldpage, struct 
page *newpage,
  */
 static int __init mem_cgroup_init(void)
 {
+   int cpu, nid;
+
hotcpu_notifier(memcg_cpu_hotplug_callback, 0);
+
+   for_each_possible_cpu(cpu)
+   INIT_WORK(_cpu_ptr(_stock, cpu)->work,
+ drain_local_stock);
+
+   for_each_node(nid) {
+   struct mem_cgroup_tree_per_node *rtpn;
+   int zone;
+
+   rtpn = kzalloc_node(sizeof(*rtpn), GFP_KERNEL, nid);
+
+   for (zone = 0; zone < MAX_NR_ZONES; zone++) {
+   struct mem_cgroup_tree_per_zone *rtpz;
+
+   rtpz = >rb_tree_per_zone[zone];
+   rtpz->rb_root = RB_ROOT;
+   spin_lock_init(>lock);
+   }
+   soft_limit_tree.rb_tree_per_node[nid] = rtpn;
+   }
+
enable_swap_cgroup();
-   mem_cgroup_soft_limit_tree_init();
-   memcg_stock_init();
+
return 0;
 }
 subsys_initcall(mem_cgroup_init);
-- 
2.2.0

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


[PATCH] Add git url for UIO section of MAINTAINERS

2015-01-09 Thread Mandeep Sandhu
This patch adds a git url entry in the UIO section of MAINTAINERS. The url is 
that of Greg KH's char-misc tree.

Mandeep Sandhu (1):
  MAINTAINERS: add git url entry for UIO

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

-- 
1.9.1

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


Re: Preemptionirqsoff latency issue

2015-01-09 Thread Davidlohr Bueso
On Fri, 2015-01-09 at 20:19 +0530, Vaibhav Shinde wrote:
> My app runs on cpu0, while other cpus looks idle; as per my
> understanding from your comment owner of the mutex is on the cpu other
> than cpu0, and which is causing wait spin on cpu0.

The thing is, cpu0 is rescheduling too often, so you're falling out of
the spinning step.

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: add git url entry for UIO

2015-01-09 Thread Mandeep Sandhu
Added git url for UIO section.

Signed-off-by: Mandeep Sandhu 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddb9ac8..9334680 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10149,6 +10149,7 @@ S:  Maintained
 F: Documentation/DocBook/uio-howto.tmpl
 F: drivers/uio/
 F: include/linux/uio*.h
+T: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
 
 UTIL-LINUX PACKAGE
 M: Karel Zak 
-- 
1.9.1

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


Re: [PATCH 04/10] clocksource: Add max_cycles to clocksource structure

2015-01-09 Thread Stephen Boyd
On 01/09/2015 04:34 PM, John Stultz wrote:
> diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
> index abcafaa..9b54cb9 100644
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -178,7 +178,7 @@ struct clocksource {
>  #ifdef CONFIG_ARCH_CLOCKSOURCE_DATA
>   struct arch_clocksource_data archdata;
>  #endif
> -
> + u64 max_cycles;

Nitpick: Update kernel-doc for new field?

>   const char *name;
>   struct list_head list;
>   int rating;
> @@ -291,7 +291,8 @@ extern struct clocksource * __init 
> clocksource_default_clock(void);
> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> index c794b84..2910f00 100644
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -126,7 +126,7 @@ void __init sched_clock_register(u64 (*read)(void), int 
> bits,
>   new_mask = CLOCKSOURCE_MASK(bits);
>  
>   /* calculate how many ns until we risk wrapping */
> - wrap = clocks_calc_max_nsecs(new_mult, new_shift, 0, new_mask);
> + wrap = clocks_calc_max_nsecs(new_mult, new_shift, 0, new_mask, 0);

Should be NULL instead of 0? Otherwise I think sparse would complain.

Otherwise:

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/10] clocksource: Simplify logic around clocksource wrapping saftey margins

2015-01-09 Thread Stephen Boyd
On 01/09/2015 04:34 PM, John Stultz wrote:
> The clocksource logic has a number of places where we try to
> include a safety margin. Most of these are 12% safety margins,
> but they are inconsistently applied and sometimes are applied
> on top of each other.
>
> Additionally, in the previous patch, we corrected an issue
> where we unintentionally in effect created a 50% saftey margin,
> which these 12.5% margins where then added to.
>
> So to siplify the logic here, this patch removes the various
> 12.5% margins, and consolidates adding the margin in one place:
> clocks_calc_max_nsecs().
>
> Addtionally, Linus prefers a 50% safety margin, as it allows
> bad clock values to be more easily caught. This should really
> have no net effect, due to the corrected issue earlier which
> caused greater then 50% margins to be used w/o issue.
>
> Cc: Dave Jones 
> Cc: Linus Torvalds 
> Cc: Thomas Gleixner 
> Cc: Richard Cochran 
> Cc: Prarit Bhargava 
> Cc: Stephen Boyd 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Signed-off-by: John Stultz 
> ---

For sched_clock.c part

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/10] clocksource: Add some debug info about clocksources being registered

2015-01-09 Thread Stephen Boyd
On 01/09/2015 04:34 PM, John Stultz wrote:
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index 9a0b951..c641aa7 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -770,6 +770,10 @@ void __clocksource_updatefreq_scale(struct clocksource 
> *cs, u32 scale, u32 freq)
>   cs->max_idle_ns = clocks_calc_max_nsecs(cs->mult, cs->shift,
>cs->maxadj, cs->mask,
>>max_cycles);
> +
> + pr_info("clocksource %s: mask: 0x%llx max_cycles: 0x%llx, max_idle_ns: 
> %lld ns\n",
> + cs->name, cs->mask, cs->max_cycles, cs->max_idle_ns);

Is this intentionally info level? Or was it supposed to be debug level
per $subject?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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


Re: [PATCH] staging, addi_apci_1500: fix IRQ spew

2015-01-09 Thread Greg KH
On Wed, Dec 10, 2014 at 02:42:01PM +, Alan Cox wrote:
> The driver very carefully checks if the card is the IRQ source, and if it
> isn't thoughtfully spews crap at_dev_warn() level. Remove the spewage so it
> can be used on a shared interrupt line.
> 
> Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=88651
> Signed-off-by: Alan Cox 
> ---
>  .../comedi/drivers/addi-data/hwdrv_apci1500.c  |4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c 
> b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
> index 0ea081e..b7b9857 100644
> --- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
> +++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1500.c
> @@ -2175,10 +2175,6 @@ static void apci1500_interrupt(int irq, void *d)
>   devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
>   /* Authorizes the main interrupt on the board */
>   outb(0xD0, devpriv->iobase + APCI1500_Z8536_CONTROL_REGISTER);
> - } else {
> - dev_warn(dev->class_dev,
> - "Interrupt from unknown source\n");
> -
>   }
>  }
>  

No longer applies to my tree due to other changes in this driver :(

thanks,

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


Re: [PATCH 3.19.0-rc3 1/1] STAGING: Fix pcl818.c coding style issue

2015-01-09 Thread Greg Kroah-Hartman
On Fri, Jan 09, 2015 at 12:20:04PM +0800, Simon Guo wrote:
> Correct coding style problem in pcl818.c. The coding style problems(29 
> warnings detected by checkpatch.pl) includes:
> - line over 80 characters
> - There is space before tabs
> The changed file has been verified with checkpatch.pl to be clean for 
> warnings/errors.

Those are different things, so there should be different patches, make
this a series please.

Also fix up your trailing whitespace in the changelog itself.

thanks,

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


Re: [PATCH] staging: unisys: Removed a prohibited space in a function parameter

2015-01-09 Thread Greg KH
On Tue, Dec 23, 2014 at 12:51:55PM +0200, Olli Lehtinen wrote:
> Fixes the checkpatch.pl error:
> ERROR: space prohibited before that ',' (ctx:WxW)" in virthba.c.
> 
> Signed-off-by: Olli Lehtinen 
> ---
>  drivers/staging/unisys/virthba/virthba.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/unisys/virthba/virthba.c
> b/drivers/staging/unisys/virthba/virthba.c
> index d7a629b..82fcb3b 100644
> --- a/drivers/staging/unisys/virthba/virthba.c
> +++ b/drivers/staging/unisys/virthba/virthba.c
> @@ -1438,7 +1438,7 @@ static ssize_t enable_ints_write(struct file *file,
>   return -EFAULT;
>   }
> 
> - i = kstrtoint(buf, 10 , _value);
> + i = kstrtoint(buf, 10, _value);
> 
>   if (i != 0) {
>   LOGERR("Failed to scan value for enable_ints, buf<<%.*s>>",
> -- 
> 1.7.10.4

This patch fails to apply for some reason :(

Please fix it up and resend.

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


Re: [PATCH] Staging: unisys: virtpci: fixed coding style errors

2015-01-09 Thread Greg KH
On Wed, Dec 17, 2014 at 05:25:10PM -0800, Andrew Milkovich wrote:
> Fixed coding style errors per checkpatch.pl. Inline comments removed.

What coding errors did you fix?  Please be specific.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Rich Felker
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
> Rich Felker  writes:
> 
> > I'm not proposing code because I'm a libc developer not a kernel
> > developer. I know what's needed for userspace to provide a conforming
> > fexecve to applications, not how to implement that on the kernel side,
> > although I'm trying to provide constructive ideas. The hostility is
> > really not necessary.
> 
> Conforming to what?
> 
> The open group fexecve says nothing about requiring a file descriptor
> passed to fexecve to have O_CLOEXEC.

It doesn't require it but it allows it, and in multithreaded programs
that might run child processes (or library code that might be used in
such situations), O_CLOEXEC is mandatory everywhere to avoid fd leaks.

> Further looking at open group specification of exec it seems to indicate
> the preferred way to handle this is for the kernel to return O_NOEXEC
> and then libc gets to figure out how to run the shell script.  Is that
> the kind of ``conforming'' implementation you are looking for?

This is a complex issue, and does not apply to native #! support
(which is a supported executable format and thus not ENOEXEC) but
rather standard POSIX shell scripts (which don't have a #! line at
all). In this case the behavior of fexecve is perhaps under-specified.
However, in cases where execve would succeed (without causing
ENOEXEC), I think it's at least undesirable, if not non-conforming,
for fexecve to fail.

Should we request clarification from the Austin Group?

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] IB/mlx4: Remove unnecessary KERN_WARNING

2015-01-09 Thread Masanari Iida
This patch remove unnecessary KERN_WARNING from pr_warn.

Signed-off-by: Masanari Iida 
---
 drivers/infiniband/hw/mlx4/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/mlx4/main.c 
b/drivers/infiniband/hw/mlx4/main.c
index 57ecc5b..6e15136 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1493,8 +1493,7 @@ static void reset_gids_task(struct work_struct *work)
   MLX4_CMD_TIME_CLASS_B,
   MLX4_CMD_WRAPPED);
if (err)
-   pr_warn(KERN_WARNING
-   "set port %d command failed\n", gw->port);
+   pr_warn("set port %d command failed\n", gw->port);
}
 
mlx4_free_cmd_mailbox(dev, mailbox);
-- 
2.2.1.268.g1e6f5b2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: blk-mq v3.18: Oops during virtio_blk hot-unplug

2015-01-09 Thread Fam Zheng
On Fri, 01/09 15:32, Sebastian Parschauer wrote:
> Hi Jens,
> 
> my colleague Eduardo is sporadically seeing an Oops in blk-mq while
> running continuous virtio_blk hot-plug/hot-unplug tests with I/O to the
> device within an x86_64 QEMU/KVM 2.0 Debian Wheezy VM.
> 
> Please find the call trace attached and the full log here:
> http://paste.ubuntu.com/9691873/
> 
> The kernel image has been taken from here and is the mainline kernel
> from tag v3.18:
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/
> 
> Is there still an issue with block queue freezing?

This one?

commit 45a9c9d909b24c6ad0e28a7946e7486e73010319
Author: Bart Van Assche 
Date:   Tue Dec 9 16:57:48 2014 +0100

blk-mq: Fix a use-after-free

Fam

> 
> We are seeing a similar issue with v3.16 but more often as some block
> queue freezing fixes have been added in v3.17.
> 
> All kernels without blk-mq used by virtio_blk (< v3.13) work fine.
> 
> Cheers,
> Sebastian

> [  165.630508] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [  165.631027] IP: [] __mutex_lock_slowpath+0x75/0x100
> [  165.631219] PGD 368a2067 PUD 797d3067 PMD 0 
> [  165.631454] Oops: 0002 [#1] SMP 
> [  165.631632] Modules linked in: parport_pc 8250_fintek pvpanic parport 
> snd_pcm snd_timer snd soundcore i2c_piix4 joydev pcspkr psmouse serio_raw 
> evbug mac_hid hid_generic usbhid hid floppy
> [  165.632010] CPU: 0 PID: 22838 Comm: dd Not tainted 3.18.0-031800-generic 
> #201412071935
> [  165.632010] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Bochs 01/01/2011
> [  165.633045] task: 8800685b6400 ti: 88007afc task.ti: 
> 88007afc
> [  165.633045] RIP: 0010:[]  [] 
> __mutex_lock_slowpath+0x75/0x100
> [  165.633045] RSP: 0018:88007afc3c38  EFLAGS: 00010297
> [  165.633045] RAX:  RBX: 880036b1fa08 RCX: 
> c100
> [  165.633045] RDX: 88007afc3c40 RSI: 8800685b6400 RDI: 
> 880036b1fa0c
> [  165.633045] RBP: 88007afc3c88 R08: 88007afc R09: 
> 
> [  165.633045] R10: 0001 R11: 0246 R12: 
> 8800685b6400
> [  165.633045] R13: 880036b1fa0c R14:  R15: 
> 880036b1fa10
> [  165.633045] FS:  7fce39352700() GS:88007fc0() 
> knlGS:
> [  165.633045] CS:  0010 DS:  ES:  CR0: 80050033
> [  165.633045] CR2:  CR3: 7ae5b000 CR4: 
> 000406f0
> [  165.633045] Stack:
> [  165.633045]  880036d552d8 880036b1fa10  
> 88007b5cf0c0
> [  165.633045]  88007afc3c98 880036b1fa08 880036d552d8 
> 880036b1f9d0
> [  165.633045]  8800795f3000 88007b5cf0c0 88007afc3ca8 
> 817b10e3
> [  165.633045] Call Trace:
> [  165.633045]  [] mutex_lock+0x23/0x37
> [  165.633045]  [] blk_mq_free_queue+0x26/0x1a0
> [  165.633045]  [] blk_release_queue+0xa2/0x100
> [  165.633045]  [] kobject_cleanup+0x82/0x1c0
> [  165.633045]  [] kobject_put+0x30/0x70
> [  165.633045]  [] blk_put_queue+0x15/0x20
> [  165.633045]  [] disk_release+0x93/0xd0
> [  165.633045]  [] device_release+0x3e/0xc0
> [  165.633045]  [] kobject_cleanup+0x82/0x1c0
> [  165.633045]  [] kobject_put+0x30/0x70
> [  165.633045]  [] put_disk+0x17/0x20
> [  165.633045]  [] __blkdev_put+0x125/0x1b0
> [  165.633045]  [] blkdev_put+0x5b/0x160
> [  165.633045]  [] blkdev_close+0x25/0x30
> [  165.633045]  [] __fput+0xbd/0x250
> [  165.633045]  [] fput+0xe/0x10
> [  165.633045]  [] task_work_run+0xa7/0xe0
> [  165.633045]  [] do_notify_resume+0xc7/0xd0
> [  165.633045]  [] int_signal+0x12/0x17
> [  165.633045] Code: 00 00 8b 03 83 f8 01 0f 84 99 00 00 00 48 8b 43 10 48 8d 
> 55 b8 4c 8d 7b 08 41 be ff ff ff ff 48 89 53 10 4c 89 7d b8 48 89 45 c0 <48> 
> 89 10 4c 89 65 c8 eb 1f 66 90 4c 89 ef 49 c7 04 24 02 00 00 
> [  165.633045] RIP  [] __mutex_lock_slowpath+0x75/0x100
> [  165.633045]  RSP 
> [  165.633045] CR2: 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

2015-01-09 Thread Eric W. Biederman
Rich Felker  writes:

> I'm not proposing code because I'm a libc developer not a kernel
> developer. I know what's needed for userspace to provide a conforming
> fexecve to applications, not how to implement that on the kernel side,
> although I'm trying to provide constructive ideas. The hostility is
> really not necessary.

Conforming to what?

The open group fexecve says nothing about requiring a file descriptor
passed to fexecve to have O_CLOEXEC.

Further looking at open group specification of exec it seems to indicate
the preferred way to handle this is for the kernel to return O_NOEXEC
and then libc gets to figure out how to run the shell script.  Is that
the kind of ``conforming'' implementation you are looking for?

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: NULL pointer dereference in i2c-hid

2015-01-09 Thread Gabriele Mazzotta
On Friday 09 January 2015 16:29:04 Andrew Duggan wrote:
> On 01/09/2015 12:04 AM, Gabriele Mazzotta wrote:
> > On Thursday 08 January 2015 15:58:54 Andrew Duggan wrote:
> >> On 12/24/2014 03:53 PM, Gabriele Mazzotta wrote:
> >> [...snip...]
> >> Also, if you can get the firmware id from your touchpad that would also
> >> be useful.
> >>
> >> $ sudo ./rmihidtool -f /dev/hidraw0
> > firmware id: 1522295
>  Thanks, I will see if I can get any additional information on this.
> 
>  Andrew
> >>> Hi,
> >>>
> >>> I think I found the source of the problem.
> >>>
> >>> $ ./rmihidtool /dev/hidraw1 -r 0x50 1
> >>> 0x01  #PalmDetect Interrupt Enable, right?
> >> Yes, 0x50 does appear to be the address of the palm detect interrupt
> >> enable register.
> >>> $ ./rmihidtool /dev/hidraw1 -w 0x50 0  #Disable PalmDetect Interrupt
> >>>
> >>> It makes more sense now that widths greater than 12 trigger the bug.
> >> That is weird behavior and I haven't seen anything like that before. I
> >> will file a bug to see if firmware has any idea why this is happening.
> > According to the RMI4 specification, gesture interrupts are cleared
> > only once specific flag registers, F11_2D_Data8 and F11_2D_Data9, are
> > read. So I tried to read those register and found that the following
> > command stops the events:
> 
> It is unusual to see firmware gestures enabled for HID/I2C touchpads. In 
> fact none of the touchpads I have have that functionality enabled, which 
> is why I haven't been able to test. On HID touchpads there is a layer in 
> the firmware which reads the RMI registers and packs them into the HID 
> attention report. My guess is that the HID layer is not reading 
> F11_2D_Data8 or 9 causing it to assert indefinitely. Since this isn't a 
> common firmware configuration that is probably why this hasn't been 
> observed before.
> 
> > $ rmihidtool /dev/hidraw1 -r 0x24 1  # I was looking for F11_2D_Data8
> >
> > I'm not sure I got the right address as reading any register close to
> > 0x24 (such as 0x25, 0x26) has the same effect. I would have expected
> > this to happen only reading one specific register.
> 
> With this firmware, F11_2D_Data8 should be at 0x3A. It's 2 bytes for 
> finger state + 5 bytes per finger * 5 fingers for abs data  + 2 bytes 
> per finger * 5 fingers for rel data. I'm not sure why reading 0x24 would 
> stop the reports though.

Yes, this seems to be the right one, I can see the things I was
expecting to see. That's why I kind of knew that 0x24 wasn't right,
but I was surprised to see the problem disappear by reading that
register, so I didn't bother do the math. Thanks for doing it for me.

Anyway, I can see PalmDetect set to 1 in register 0x3B and the
interrupts stop as soon as I read it.

> >
> > I also honestly don't know why palms are detected when the width is at
> > least 12, PalmDetectThreshold is 0 and so the palm detection should
> > be inhibited.
> >
> 
> This seems to be set in the firmware config. It looks like 
> PalmDetectThreshold is only used when the reporting mode is 001. The 
> default reporting mode looks like it is 000.

For some reason, mode 001 is not working. I tried it time ago as an
attempt to reduce the power consumption, but as soon as switched to it,
the touchpad stopped working as intended. In that mode, nothing happens
until I click and when I do that, I can see something going on while
I move the finger. But this has nothing to do with the problem here
discussed. The interesting thing is that whichever mode I set, as soon
as the width of the finger reaches 12, everything starts working as
if the reporting mode was 000. This means that as long as the palm
detect interrupt is enabled, palms are detected regardless of the mode.

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


  1   2   3   4   5   6   7   8   9   10   >