On Thu, 2014-11-20 at 09:47 -0800, Dmitry Torokhov wrote:
> Hi Oliver,
>
> On Thu, Nov 20, 2014 at 11:31:30AM +0100, Oliver Neukum wrote:
> > > +static int elants_i2c_initialize(struct elants_data *ts)
> > > +{
> > > + struct i2c_client *client =
_cnt < MAX_RETRIES - 1)
> + continue;
> + }
Regards
Oliver
--
Oliver Neukum
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Mon, 2014-11-17 at 09:32 -0600, Bryan Poling wrote:
> I tried making patch files but was not successful (I may try again). I
> hope somebody can add this though. Thanks, and best regards.
I made and submitted a patch. What step did you fail at?
Regards
Oliver
--
To
me
> protection isn't there when clearing needs_remote_wakeup. This will
> add that to usbhid_close as well as usbhid_stop.
Interesting, but this has the side effect of waking devices
that are asleep just to remove the flag.
Regards
Oliver
--
Oliver Neukum
-
+ else
> + total_length += current_kvec->iov_len;
> + }
> +
> + return total_length;
> +}
> +
Regards
Oliver
--
Oliver Neukum
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On Wed, 2014-11-12 at 10:51 +0100, Castle OfWhite wrote:
> "We are unable to post your comment because you have been blocked by
> Vitavonni. Find out more."
We don't care. This is the kernel list. Take that elsewhere.
Oliver
--
To unsubscribe from this list: send the line "unsubscribe l
root hub. One instance
> + * exists per root hub.
> + */
> +struct __attribute__((__packed__)) mausb_root_hub {
Why __packed__ ?
> +
> + /* hub parameters */
> + struct usb_hub_descriptor descriptor;
> + struct usb_hub_status status;
> +
> + /* port parameters*/
> + struct usb_port_statusport_status[MAUSB_ROOTHUB_NUM_PORTS];
> +
> + /* root hub state */
> + enum mausb_rh_state rh_state;
> +
> +};
HTH
Oliver
--
Oliver Neukum
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 2014-11-11 at 20:02 -0500, Mathy Vanhoef wrote:
> On 11/10/2014 04:08 AM, Oliver Neukum wrote:
> > Which means that you are freeing memory that may still be used by DMA
> > at this time.
> > In addition you have no guarantee that the unlink is indeed finished
>
kfree(tmpbuf);
Which means that you are freeing memory that may still be used by DMA
at this time.
In addition you have no guarantee that the unlink is indeed finished
by the time the URB is reused.
If you wish to take this approach you better forget about this URB
and allocate a new one and free the
On Fri, 2014-11-07 at 10:16 +0100, Johan Hovold wrote:
> On Fri, Nov 07, 2014 at 10:05:12AM +0100, Oliver Neukum wrote:
> > On Thu, 2014-11-06 at 18:08 +0100, Johan Hovold wrote:
> > > Add new quirk for devices that cannot handle control-line state
> > > requests
On Thu, 2014-11-06 at 18:08 +0100, Johan Hovold wrote:
> Add new quirk for devices that cannot handle control-line state
> requests.
>
> Note that we currently send these requests to all devices, regardless
> of
> whether they claim to support it, but that errors are only logged if
> support is cl
he device when the port is activated.
> >
> > Signed-off-by: Jim Paris
>
> Reviewed-by: Johan Hovold
Acked-by: Oliver Neukum
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordo
Hi,
I am running XFS on top of bcache. Apparmor
is enabled on my system. I am seeing tons of warnings like this:
2014-10-30T11:39:38.774440+01:00 linux-0dmf kernel: [ 650.901837]
WARNING: CPU: 2 PID: 2378 at mm/truncate.c:758 pagecache_isize_extended
+0xfd/0x110()
2014-10-30T11:39:38.774441+01:0
On Wed, 2014-10-29 at 16:58 +0100, Johan Hovold wrote:
> On Wed, Oct 29, 2014 at 11:56:02PM +0800, Greg Kroah-Hartman wrote:
> > This should go to older kernels as well, right?
>
> Yes, if you want.
>
> It's fixing handling of B0, but I doubt many people care (hence the
> missing stable tag). No
On Thu, 2014-10-23 at 01:52 -0700, russ.d...@gmail.com wrote:
> From: Russ Dill
>
> This patch provides the FTDI genuine product verification steps
> as contained within the new 2.12.00 official release. It ensures
> that counterfeiters don't exploit engineering investment made
> by FTDI. Counter
On Thu, 2014-10-23 at 01:52 -0700, russ.d...@gmail.com wrote:
> From: Russ Dill
>
> This patch provides the FTDI genuine product verification steps
> as contained within the new 2.12.00 official release. It ensures
> that counterfeiters don't exploit engineering investment made
> by FTDI. Counter
On Fri, 2014-10-17 at 13:55 +0800, Hayes Wang wrote:
> It would cause dead lock for runtime suspend, when the workqueue
> is running and runtime suspend occurs before the workqueue wakes
> up the device. The rtl8152_suspend() waits the workqueue to finish
> because of calling cancel_delayed_work_sy
On Fri, 2014-10-03 at 16:36 -0600, Dennis Gesker wrote:
> Displaylink USB 3.0 Attached Display Adapater and Monitor Not Recognized
> DisplayLink Plug and Play Universal docking Station
> DELL
> Model: D3000
> MFG: ACP075US
> SN: 1309017059
>
>
> Apologies in advance if I'm posting to the wrong li
On Thu, 2014-10-02 at 16:26 +0800, Hayes Wang wrote:
> Resume the device before setting the MAC address.
>
> Signed-off-by: Hayes Wang
> ---
> drivers/net/usb/r8152.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net
On Fri, 2014-09-05 at 16:17 +0100, Nix wrote:
> On 5 Sep 2014, Oliver Neukum verbalised:
>
> > On Fri, 2014-09-05 at 00:40 +0100, Nix wrote:
> >> I'm working around this confusing morass by rebooting into each test
> >> kernel, unplugging and repluggin
On Fri, 2014-09-05 at 00:40 +0100, Nix wrote:
> I'm working around this confusing morass by rebooting into each test
> kernel, unplugging and replugging the entropy key if it was fubared,
> then rebooting into the same kernel again and seeing if it was still
> fubared. But this is not terribly fast
> I'll do a bisection of the cdc-acm changes since 3.15 tomorrow night and
> see if I can find the commit at fault.
Thank you for the report. Please let me know the results of your
bisection.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe l
On Tue, 2014-08-05 at 16:30 -0400, Nick Krause wrote:
> I understand if you don't want to give me a second change , but if you want to
> help me learn, I would love to be cced into anything I can learn from. In
> terms of subsystems support I would like to help out in a few. My list is
> below.
>
On Thu, 2014-07-10 at 14:11 +0100, Scot Doyle wrote:
> Hi Olof,
>
> Have these been applied? If not, where should I watch for them?
Hi,
could you tell me from which tree I could get these patches?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubsc
On Wed, 2014-07-30 at 10:36 +1000, Stephen Rothwell wrote:
> Caused by commit 20fbe3ae990f ("cdc_subset: deal with a device that
> needs reset for timeout").
>
> I have used the net tree from next-20140729 for today (i.e. up to
> commit fe26566d8a0515 ("bnx2x: fix crash during TSO tunneling")).
On Fri, 2014-07-25 at 17:43 +0400, Sergey Klyaus wrote:
> Hello.
>
> I am currently working on a project with Thin clients with Citrix
> Receiver 13 for Linux and encountered interesting problem with USB
> device redirection.
> ctxusb/ctxusbd process from Citrix Receiver are using inotify mechan
On Thu, 2014-07-24 at 10:18 +0200, Fabian Frederick wrote:
> Small patchset addressing break redundancy on drivers/usb branch
> (suggested by Joe Perches).
Frankly, that is not a good idea. Somebody will remove a "goto"
and forget to readd the "break"
Regards
Oliver
--
T
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
> > Applications can already check the lid status (through UPower), and with
> > the additional metadata from the kernel, know that the webcam won't be
> > usable when the lid
On Wed, 2014-07-16 at 14:08 -0400, Alan Stern wrote:
> > I am not so much concerned about userspace, but about reusing of as
> > much of existing PM framework in the drivers. Right now it is very
> > hard to correctly track dependencies between general open/close,
> > system suspend/resume, and var
On Wed, 2014-07-02 at 17:53 +0200, Stefan Klug wrote:
> @@ -1471,6 +1526,57 @@ static int proc_do_submiturb(struct
> usb_dev_state
> *ps, struct usbdevfs_urb *uurb
> }
> totlen -= u;
> }
> +} else if(num_pages) {
> +pages = kmalloc(num_pages*sizeo
On Wed, 2014-07-02 at 17:53 +0200, Stefan Klug wrote:
> Implementation details:
> The patch only touches drivers/usb/core/devio.c.
> In procy_do_submiturb(), it is checked if zerocopy is allowed. This is
> currently a rough
> check which compares the number of required pages to
> ps->dev->bus->s
On Thu, 2014-06-26 at 22:20 +0200, Pavel Machek wrote:
> Hi!
>
> Ok, this ext4 filesystem does _not_ have easy life: it is in usb
> envelope, I wanted
> to use it as a root filesystem, and it is connected to OLPC-1.75,
> running some kind
> of linux-3.0 kernels.
>
> So power disconnects are commo
On Wed, 2014-06-18 at 19:05 +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> +static int gt683r_led_probe(struct hid_device *hdev,
> + const struct hid_device_id *id)
> +{
> + int i;
> + int
On Fri, 2014-06-20 at 22:40 +0200, Fabian Frederick wrote:
> inline this one line function used in driver_info structure
That precisely is this the reason not to inline this.
It is used as a function pointer. gcc must generate
a non-inlined version of the function.
Your patch has zero effect and
On Mon, 2014-06-16 at 11:25 +0300, Mika Westerberg wrote:
> On Thu, Jun 12, 2014 at 03:27:01PM +0200, Oliver Neukum wrote:
> > I am looking at the patch set you posted for making
> > the touchpad of those laptops work. Has anything happened
> > regarding i2c so that the pa
Hi Benson,
I am looking at the patch set you posted for making
the touchpad of those laptops work. Has anything happened
regarding i2c so that the patches can go upstream?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
ing boilerplate) since I converted it to use the generic
> implementation a few years ago.
>
> Oliver and Mathias, what do you think of this? Would you be willing to
> sign off on this patch?
Signed-off-by: Oliver Neukum
Regards
Oliver
--
To unsubscribe fr
On Sun, 2014-05-18 at 21:50 +0200, Guennadi Liakhovetski wrote:
> On Sun, 18 May 2014, Rickard Strandqvist wrote:
>
> > There is otherwise a risk of a possible null pointer dereference.
> >
> > Was largely found by using a static code analysis program called cppcheck.
> >
> > Signed-off-by: Rick
On Thu, 2014-04-24 at 12:32 +0200, Michal Malý wrote:
> On Wednesday 23 of April 2014 15:41:03 Oliver Neukum wrote:
> > On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> > > static int drff_play(struct input_dev *dev, void *data,
> > >
> > > -
On Wed, 2014-04-23 at 08:59 -0700, Dmitry Torokhov wrote:
> On Wed, Apr 23, 2014 at 02:12:59PM +0200, Oliver Neukum wrote:
> > On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> > > +/* Some devices might have a limit on how many uncombinable effects
> > >
On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> static int drff_play(struct input_dev *dev, void *data,
> -struct ff_effect *effect)
> + const struct mlnx_effect_command *command)
> {
> struct hid_device *hid = input_get_drvdat
On Wed, 2014-04-23 at 14:30 +0200, Michal Malý wrote:
> > 2. That is needlessly inefficient
> Are you suggesting I drop the 'consts' and keep the memory preallocated?
Yes.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> static int holtekff_play(struct input_dev *dev, void *data,
> -struct ff_effect *effect)
> +const struct mlnx_effect_command *command)
> {
> struct hid_device *hid = input_get_drvdata(d
On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> +/* Some devices might have a limit on how many uncombinable effects
> + * can be played at once */
> +static int mlnx_upload_conditional(struct mlnx_device *mlnxdev,
> + const struct ff_effect *effect)
> +{
>
On Wed, 2014-04-16 at 11:26 -0400, Alan Stern wrote:
> On Wed, 16 Apr 2014, Oliver Neukum wrote:
>
> > Hi,
> >
> > I am looking at memory ordering and a question hit me.
> > I was looking at the kfifo code. kfifo_put() has a barrier:
> >
> >
On Thu, 2014-04-17 at 11:50 -0400, Alan Stern wrote:
> On Thu, 17 Apr 2014, Oliver Neukum wrote:
>
> > On Wed, 2014-04-16 at 11:26 -0400, Alan Stern wrote:
> >
> > > In addition, the following code in kfifo_get() does this:
> > >
> > >
On Thu, 2014-04-17 at 11:50 -0400, Alan Stern wrote:
> On Thu, 17 Apr 2014, Oliver Neukum wrote:
>
> > On Wed, 2014-04-16 at 11:26 -0400, Alan Stern wrote:
> >
> > > In addition, the following code in kfifo_get() does this:
> > >
> > >
On Wed, 2014-04-16 at 11:26 -0400, Alan Stern wrote:
> In addition, the following code in kfifo_get() does this:
>
> *(typeof(__tmp->type))__val = \
> (__is_kfifo_ptr(__tmp) ? \
> ((typeof(__tmp->type))__kfifo->data
Hi,
I am looking at memory ordering and a question hit me.
I was looking at the kfifo code. kfifo_put() has a barrier:
)[__kfifo->in & __tmp->kfifo.mask] = \
(typeof(*__tmp->type))__val; \
smp_wmb(); \
On Mon, 2014-04-14 at 21:58 +0200, Johan Hovold wrote:
> Fix this by implementing a delayed-write queue using urb anchors and
> making sure to discard the queue properly at shutdown.
Looks very good, with one exception: acm_tty_close() must
synchronously resume the device so that the anchor is em
On Mon, 2014-04-14 at 13:53 +0100, One Thousand Gnomes wrote:
> On Fri, 11 Apr 2014 11:41:24 +0200
> Johan Hovold wrote:
>
> > Fix characters being dropped by n_tty_write() due to a failure to
> > check the return value of tty_put_char() in do_output_char().
> >
> > Characters are currently bein
avoid double decrement of USB interface's PM-usage counter.
>
> Found by Linux Driver Verification project (linuxtesting.org).
Nice catch.
> Signed-off-by: Alexey Khoroshilov
Acked-by: Oliver Neukum
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, 2014-04-11 at 11:28 +0100, Lee Jones wrote:
> > > From: Roger Tseng
> > >
> > > This patchset adds modules to support Realtek USB vendor specific class
> > > flash
> > > card reader: one base module in MFD subsystem and two host modules in
> > > both mmc
> > > and memstick subsystems. T
On Fri, 2014-04-11 at 06:51 +0800, Xiao Jin wrote:
> Hi, Oliver,
>
> On 04/10/2014 04:02 PM, Oliver Neukum wrote:
> > On Wed, 2014-04-09 at 22:57 +0800, Xiao Jin wrote:
> >> Thanks all for the review. We meet with the problems when developing
> >> product. I would
On Fri, 2014-04-11 at 14:53 +0800, rogera...@realtek.com wrote:
> From: Roger Tseng
>
> This patchset adds modules to support Realtek USB vendor specific class flash
> card reader: one base module in MFD subsystem and two host modules in both mmc
> and memstick subsystems. The architecture is sim
On Wed, 2014-04-09 at 22:57 +0800, Xiao Jin wrote:
> Thanks all for the review. We meet with the problems when developing
> product. I would like to explain my understanding.
>
> On 04/08/2014 11:05 AM, Xiao Jin wrote:
> >
> > We find two problems on acm tty write delayed mechanism.
> > (1) When
On Tue, 2014-04-08 at 15:17 +0200, Johan Hovold wrote:
> [ +CC: Alan ]
>
> On Tue, Apr 08, 2014 at 12:33:31PM +0200, Oliver Neukum wrote:
> > On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote:
> > > On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
>
On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote:
> On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
> > (2) acm tty port ASYNCB_INITIALIZED flag will be cleared when
> > close. If acm resume callback run after ASYNCB_INITIALIZED flag
> > cleared, there will have no chance for delaye
is not happy
when you accept no data. But we should be able to refuse subsequent
writes. Could you test this patch?
Regards
Oliver
>From 1d44c1f2a10b5617824a37c8ec51f5547e482259 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Tue, 8 Apr 2014 12:17:39 +0200
Subject: [PAT
On Fri, 2014-03-28 at 11:33 +0800, Roger wrote:
> On 03/26/2014 10:36 PM, Oliver Neukum wrote:
> > On Tue, 2014-03-25 at 18:44 +0800, rogera...@realtek.com wrote:
> >> From: Roger Tseng
> >> + if (ret)
> >> + goto out_init_fail;
> >>
On Tue, 2014-03-25 at 18:44 +0800, rogera...@realtek.com wrote:
> From: Roger Tseng
> +static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
> + unsigned int pipe, struct scatterlist *sg, int num_sg,
> + unsigned int length, unsigned int *act_len, int timeout)
> +
On Fri, 2014-03-21 at 12:18 +, jimmie.da...@l-3com.com wrote:
>
> >How is that different from any other time a task has to yield the CPU
> >for a bit? While your high priority task is blocked for whatever
> >reason, a lower priority task gets to use the CPU.
>
>
> As the submitter of the
On Fri, 2014-03-21 at 17:17 +0530, Jagdish Gedia wrote:
> I want to resume the usb device on some event, so i want to check if
> it is suspended. I think by above method i can check if the device is
> already suspended, but may be i will miss to resume the device if it
> is suspending. Is there any
On Thu, 2014-03-13 at 17:13 +0530, Jagdish Gedia wrote:
> Hi,
> I want to check in my driver if usb device is suspended or not?
> currently i am doing it like
>
> if(udev->state==USB_STATE_SUSPENDED)
>
> Is this the proper way? Is this enough?
This question is near meaningless. Assuming that you
On Mon, 2014-02-17 at 21:23 +0800, Daniel J Blueman wrote:
> Across 5+ years of kernels, I've been seeing occasional (1-2 times per
> day) key-stuck issues where eg a fn+delete combo repeats delete until
> I press delete again. I've seen this happen with fn+ctrl+left, leaving
> left held and likewi
On Mon, 2014-02-10 at 16:54 +0100, Emil Goode wrote:
> Since the checks that need to be added in various places are all in
> the same subsystem I think it could be done in as little as one patch?
Yes, please definitely. Best for bisectability.
> If nobody have any objections I will try removing
On Mon, 2014-02-10 at 13:00 +0100, Emil Goode wrote:
> On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote:
> > On Mon, 2014-02-10 at 00:06 +0100, Emil Goode wrote:
> > > The AX88772B occasionally send rx packets that cross urb boundaries
> > > and the remai
On Mon, 2014-02-10 at 12:04 +0800, Yijing Wang wrote:
> +static u64 pci_device_serial_number(struct pci_bus *bus, int devfn)
> +{
> + int pos;
> + u32 lo, hi;
> +
> + if (!pci_bus_find_capability(bus, devfn, PCI_CAP_ID_EXP))
> + return 0;
> +
> + pos = pci_bus
On Mon, 2014-02-10 at 15:59 +0800, Yijing Wang wrote:
> Hi Oliver,
>Thanks for your review and comments!
>
> >> +static DEFINE_SPINLOCK(pci_freeze_lock);
> >
> > The lock is used only here.
>
> Also be used in pci_bus_unfreeze_device();
Sorry, I meant only in this patch.
>
> >
> >> +/**
On Mon, 2014-02-10 at 12:04 +0800, Yijing Wang wrote:
> +static DEFINE_SPINLOCK(pci_freeze_lock);
The lock is used only here.
> +/**
> + * pci_bus_freeze_device - freeze pci bus to access pci device
> + * @bus: the pci bus to freeze
> + *
> + * Replace pci bus ops by pci_dummy_ops, protect syste
On Mon, 2014-02-10 at 00:06 +0100, Emil Goode wrote:
> The AX88772B occasionally send rx packets that cross urb boundaries
> and the remaining partial packet is sent with no hardware header.
> When the buffer with a partial packet is of less number of octets
> than the value of hard_header_len the
On Thu, 2014-01-30 at 01:52 -0800, Joe Perches wrote:
> On Thu, 2014-01-30 at 08:35 +0100, Oliver Neukum wrote:
> > On Wed, 2014-01-29 at 15:46 -0800, Joe Perches wrote:
> >
> > > > +static int cp2112_hid_get(struct hid_device *hdev, unsigned
On Wed, 2014-01-29 at 15:46 -0800, Joe Perches wrote:
> > +static int cp2112_hid_get(struct hid_device *hdev, unsigned char
> > report_number,
> > + u8 *data, size_t count, unsigned char report_type)
> > +{
> > + u8 *buf;
> > + int ret;
> > +
> > + buf = kmalloc(count, G
On Thu, 2014-01-16 at 15:52 -0600, David Barksdale wrote:
> +enum {
> + STATUS1_TIMEOUT_NACK = 0x00,
> + STATUS1_TIMEOUT_BUS = 0x01,
> + STATUS1_ARBITRATION_LOST = 0x02,
> + STATUS1_READ_INCOMPLETE = 0x03,
> + STATUS1_WRITE_INCOMPLETE = 0x04,
> + STATUS1_SUCCESS = 0x05,
> +
On Mon, 2013-12-23 at 17:52 +0800, rogera...@realtek.com wrote:
> From: Roger Tseng
>
> Realtek USB SD/MMC host driver provides mmc host support based on the Realtek
> USB card reader MFD driver.
>
> Signed-off-by: Roger Tseng
> +#ifdef DEBUG
Dynamic debugging would be nice.
> +static void s
On Mon, 2013-12-23 at 17:52 +0800, rogera...@realtek.com wrote:
> From: Roger Tseng
>
> Realtek USB card reader provides a channel to transfer command or data to
> flash
> memory cards. This driver exports host instances for mmc and memstick
> subsystems
> and handles basic works.
Thank you fo
On Thu, 2014-01-02 at 16:03 -0800, Sarah Sharp wrote:
> That means your system worked fine in 3.13-rc3 (when the quirk was
> applied broadly), but won't work for 3.13-rc6 (when the quirk was
> narrowed to HP machines). So we need the quirk to apply to your
> systems
> as well.
>
> ISTR that the o
On Mon, 2013-12-09 at 19:09 +, Matthew Garrett wrote:
> Acceptable but increasingly socially frowned upon. Of the set you
> commented on, one was unclear as a result of the transition. I've
> examined the rest and am fairly happy with their clarity, but, well,
> that's the point of review.
I
On Mon, 2013-12-09 at 15:14 +0530, Vishal Annapurve wrote:
> Hi Greg,
>
> Attached are the patches.
Hi,
please send patches in the clear, inline, one patch per mail
and with a "Signed-off-by" line, as described in the Documentation
directory of the kernel.
Regards
Oliver
On Sun, 2013-12-08 at 12:52 +0100, Udo van den Heuvel wrote:
> Hello,
>
> Can someone please summarise the status of the xhci_hcd debugging I
> found after booting into 3.12.2?
> I did not see these messages before and I do not yet understand the
> added value for a mere user of this exciting xhci
On Thu, 2013-11-21 at 20:41 -0500, Alejandro Bonilla wrote:
> But xrandr is not recognizing the device/screen.
>
> So the question is, which driver supports it, the UDL or UDLFB driver?
udl is necessary.
HTH
Oliver
--
To unsubscribe from this list: send the line "unsub
On Fri, 2013-11-15 at 17:53 -0200, Geyslan Gregório Bem wrote:
Hi,
> Hi guys,
>
> In the function msgin_qtag() [line 2632], this dereference was intentional?
>
> static struct ScsiReqBlk *msgin_qtag(struct AdapterCtlBlk *acb,
> struct DeviceCtlBlk *dcb, u8 tag)
> {
> struct ScsiReqB
t; the race is due to unprotection of dev->wait, so this patch involves a
> spinlock to avoid it.
>
> Signed-off-by: wang, biao
> Signed-off-by: Zhang, Di
Acked-by: Oliver Neukum
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
e 1, declare unlink_wakeup in global section instead of on stack.
> for issue 2, use a temporary local var to keep the value of dev->wait
> in stack and judge it before using.
>
> Signed-off-by: wang, biao
> Acked-by: Ingo Molnar
> Acked-by: Oliver Neukum
Well, I didn
On Mon, 2013-11-11 at 11:08 +0800, wangbiao wrote:
> From: wang, biao
> Date: Mon, 11 Nov 2013 10:23:40 +0800
> Subject: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
>
> there is race between usbnet_terminate_urbs and usbnet_bh, when
> unlink_wakeup used in usbnet_bh, it may
On Fri, 2013-11-01 at 12:35 +0100, Bjørn Mork wrote:
> So I believe we should do the update unconditionally, and but skip
> usb_autopm_put_interface if the get failed. Accordingly, these
> functions should always return 0 (not that there is anything currently
> checking the return anyway).
>
> I
On Thu, 2013-10-24 at 18:26 +0900, hyunhee.kim wrote:
> Hi,
>
> Thanks for your review.
> I resent patch v3 after removing wrong wrapping.
>
> I made one toggle function because enable/disable functions have redundant
> codes and another reviewer suggested it.
> Is it better to separate it into
On Thu, 2013-10-24 at 15:35 +0900, hyunhee.kim wrote:
Hi,
first of all your mail client mangled the patch.
> +static void regulator_haptic_toggle(struct regulator_haptic *haptic, bool
> enable)
> +{
> + int ret;
> +
> + mutex_lock(&haptic->mutex);
> + if (enable && !haptic->enabled)
On Mon, 2013-09-30 at 04:50 +, Enrico Mioso wrote:
> +static int huawei_cdc_ncm_manage_power(struct usbnet *usbnet_dev, int on)
> +{
> + struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
> + int rv = 0;
> +
> + if ((on && atomic_add_return(1, &drvstate->pmcount) ==
On Fri, 2013-09-27 at 16:50 +0200, Peter Zijlstra wrote:
> On Fri, Sep 27, 2013 at 07:34:55AM -0700, Joe Perches wrote:
> > That would make it seem as if all barriers are SMP no?
>
> I would think any memory barrier is ordering against someone else; if
> not smp then a device/hardware -- like for
On Thu, 2013-09-19 at 02:07 +0100, Ken O'Brien wrote:
> Hi,
>
> I've acquired a Belkin "Mini Bluetooth v4.0 Adapter" F8T065bf
> 8830bf12557 Rev. A01.
>
> I'm running Linux 3.7.10-1.16 (openSUSE 12.3) and this device is not
> detecting beyond what I can see in lsusb.
That usually means that it is
On Mon, 2013-09-16 at 10:33 +, Morales, Alejandra wrote:
> 2013/9/9 Oliver Neukum
> >
> > Your prime suspect is the detection of medium change which was
> > moved into the kernel in 3.2 or so. It can be disabled by sysfs.
> > Generally the notion that a certain task
On Mon, 2013-09-16 at 11:44 +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 16, 2013 at 10:40:00AM +0200, Oliver Neukum wrote:
> > On Mon, 2013-09-16 at 13:38 +0930, Rusty Russell wrote:
> > > Predates git, does anyone remember the rationale?
> > >
> > > i
On Mon, 2013-09-16 at 13:38 +0930, Rusty Russell wrote:
> Predates git, does anyone remember the rationale?
>
> ie:
> int test_bit(int nr, const volatile unsigned long *addr)
>
> I noticed because gcc failed to elimiate some code in a patch I was
> playing with.
>
> I'm nervous about sub
On Mon, 2013-09-09 at 08:20 +, Morales, Alejandra wrote:
> mounted and there is no application using them at the moment, so that
> I was expecting that none
> of them receive file system requests. Indeed the SATA HD does not
> receive any requests unless I
> mount or unmount it, but the USB HD
On Mon, 2013-09-02 at 13:25 +0200, Gerd Hoffmann wrote:
> +static void uas_zap_dead(struct uas_dev_info *devinfo)
> +{
> + struct uas_cmd_info *cmdinfo;
> + struct uas_cmd_info *temp;
> + struct list_head list;
> + unsigned long flags;
> +
> + spin_lock_irq(&uas_lists_
On Fri, 2013-08-16 at 22:25 +0200, Yann Cantin wrote:
> +/* IRQ */
> +static int ebeam_read_data(struct ebeam_device *ebeam, unsigned char *pkt)
> +{
> +
> +/*
> + * Packet description : 8 bytes
> + *
> + * nop packet : FF FF FF FF FF FF FF FF
> + *
> + * pkt[0] : Sensors
> + * bit 1 : ultraso
On Tue, 2013-08-13 at 20:32 +0800, hayeswang wrote:
> Oliver Neukum [mailto:oneu...@suse.de]
> > Sent: Tuesday, August 13, 2013 4:49 PM
> > To: Hayeswang
> > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-...@vger.kernel.org
> > Subject:
On Tue, 2013-08-13 at 15:28 +0800, Hayes Wang wrote:
> +
> +static void rx_bottom(struct r8152 *tp)
> +{
> + struct net_device_stats *stats;
> + struct net_device *netdev;
> + struct rx_agg *agg;
> + struct rx_desc *rx_desc;
> + unsigned long lockflags;
> + struc
On Tue, 2013-07-30 at 16:19 -0700, David Miller wrote:
> From: Samuel Williams
> Date: Sat, 27 Jul 2013 15:35:54 -0500
>
> > A possible faulty hardware might interrupt with a status of 0x which
> > may kernel panic if sky2 driver tries to handle it. Detecting this problem
> > may avoid ke
501 - 600 of 1050 matches
Mail list logo
