e.
> + for (retry_cnt = 0; retry_cnt < MAX_RETRIES; retry_cnt++) {
> + error = elants_i2c_sw_reset(client);
> + if (error) {
> + /* Continue initializing if it's the last try
> */
> + if (retry_cnt < MAX_RETRIES - 1)
&
);
+ if (error) {
+ /* Continue initializing if it's the last try
*/
+ if (retry_cnt MAX_RETRIES - 1)
+ continue;
+ }
Regards
Oliver
--
Oliver Neukum oneu...@suse.de
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 = ts-client;
+ int error, retry_cnt
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
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
-
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 oneu...@suse.de
--
To unsubscribe from
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 message to majord
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
. 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/
parameters*/
+ struct usb_port_statusport_status[MAUSB_ROOTHUB_NUM_PORTS];
+
+ /* root hub state */
+ enum mausb_rh_state rh_state;
+
+};
HTH
Oliver
--
Oliver Neukum oneu...@suse.de
--
To unsubscribe from this list: send the line unsubscribe
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
;
+}
+
Regards
Oliver
--
Oliver Neukum oneu...@suse.de
--
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
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
&g
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
by the time the URB is reused
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
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 buffer from the callback.
Regards
Oliver
--
Oliver Neukum
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
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 claimed.
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.
Note that we currently send
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 majordomo in
is activated.
Signed-off-by: Jim Paris j...@jtan.com
Reviewed-by: Johan Hovold jo...@kernel.org
Acked-by: Oliver Neukum oneu...@suse.de
--
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
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()
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).
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). Note that
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()
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.
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.
On Thu, 2014-10-23 at 01:52 -0700, russ.d...@gmail.com wrote:
From: Russ Dill russ.d...@gmail.com
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
On Thu, 2014-10-23 at 01:52 -0700, russ.d...@gmail.com wrote:
From: Russ Dill russ.d...@gmail.com
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
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
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
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
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 list.
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
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 hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c
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 replugging the
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 replugging the entropy key if it was fubared,
then rebooting
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
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
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
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 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.
1.
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
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
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 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)).
Thank
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
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 mechanism
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
--
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
--
To
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
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 is
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
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 various
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 =
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 =
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
>
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
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
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 common, and
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 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 ret;
+
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
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 patches can go upstream?
Benson
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
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
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
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 oli...@neukum.org
Regards
Oliver
--
To unsubscribe from this list: send
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:
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: Rickard
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 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,
-struct ff_effect *effect
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 =
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
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 =
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-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
+ * can be played at once */
+static int
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 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(dev);
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 body
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 =
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 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:
)[__kfifo-in __tmp-kfifo.mask
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 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:
*(typeof(__tmp-type))__val
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:
*(typeof(__tmp-type))__val
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) ? \
>
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(); \
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
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
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
901 - 1000 of 1995 matches
Mail list logo
