input_dev->id.bustype = hid->bus;
> - input_dev->id.vendor = hid->vendor;
> - input_dev->id.product = hid->product;
> - input_dev->id.version = hid->version;
> -
g in a particular way internally, that spells
> disaster. There must be some other way in which the same effect can be
> achieved?
The changelog doesn't seem to be really verbose enough to me.
What exactly is the scenario you are looking at here, Benjamin, please?
Thanks,
--
Jir
On Fri, 23 Nov 2012, Benjamin Tissoires wrote:
> This just refactors the allocation of hid_input.
> No semantic changes.
As this is a generic cleanup, I am taking this one through
for-3.8/upstream branch.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send th
errupts go away.
My understanding from the other mail is that DAniel Vetter already has an
idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
this datapoint regarding MSI will fit into it.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "
rnel.org/r/alpine.lnx.2.00.1303151424140.9...@pobox.suse.cz
> Cc: Shawn Starr
> Cc: Jiri Kosina
> Cc: Daniel Vetter
Unfortunately I can't provide my Tested-by or Acked-by for this, as I am
still seeing the "nobody cared" for irq 16 with this patch applied.
> ---
> dri
On Mon, 18 Mar 2013, Josh Boyer wrote:
> This device has an odd HID entry
I can't really say I understand this portion of the changelog.
I will rephrase it a little bit and apply, thanks.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe lin
On Mon, 18 Mar 2013, Josh Boyer wrote:
> This keyboard backlight device causes a 10 second delay to boot. Add it
> to the quirk list with HID_QUIRK_NO_INIT_REPORTS.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
Okay, so I think that for 3.9 we want the patch below, and if eventually
hardware root cause / workaround is found for GM45, we can have it merged
later.
From: Jiri Kosina
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for
ng. I shall hang
> my head in shame and send a fixed v2. My apologies.
I have already fixed that in my tree, no need to resend.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
idance code and replaces it with the same trick Paulo used to
> fix pch irq handling races.
Unfortunately it didn't change anything, the spurious interrupt report is
still there.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
th IRQ acking on GM45 chipsets; hopefully
> > this datapoint regarding MSI will fit into it.
>
> What is /proc/interrupts difference between with and without pci=nomsi ?
>
> drm is forced to share irq 16?
Yup, IRQ 16 is being shared, and one of the owners is i915.
--
Jiri Kosina
SUSE
so 3.10
is definitely a realistic target.
Just to set my own expectations correctly -- Henrik, are you going to
review this patchset as well, or there is no need for me to wait for your
feedback?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe
out
should work and it indeed does in my case, hence the (tested) patch
below.
I think it's a 3.9-rc material, and I am all open to debug this further
for 3.10 so that the race is closed and gmbus irqs can be used on Gen4
platform properly.
From: Jiri Kosina
Subject: [PATCH]
Properly check return value from bus_register() and propagate it out of
tiocx_init() in case of failure.
Reported-by: Fengguang Wu
Signed-off-by: Jiri Kosina
---
arch/ia64/sn/kernel/tiocx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/ia64/sn/kernel
t, I have been thinking of writing a
> test driver module, with a module parameter telling it which IRQ number
> to register for. It seems like the sort of thing that would be useful
> to have, from time to time.
Ok, so how about this?
Daniel, is it enough to make the problem appe
CI hotplug bridges
The problem is still there ... so the inconsistency between DisINTx+ and
INTx+ is unfortunately not the whole story.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
On Wed, 20 Mar 2013, Alan Stern wrote:
> > Ok, so how about this?
> > Daniel, is it enough to make the problem appear on your system (by
> > building this into the kernel and booting with dummy-irq.irq=16)?
> >
> > Thanks.
> >
> > From: Jiri Kosina
&
er;
> > + if (hdrv && hdrv->report)
> > + hdrv->report(hid, report);
>
> I think this is more useful if called before the individual fields. In
> fact, it seems raw_event() is already doing exactly that. No need for
> a new callba
is?
Absolutely, now applied. Thanks,
--
Jiri Kosina
SUSE Labs
--
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/
so, Benjamin, perhaps it'd make sense to put a link somewhere into
in-tree documentation, with pointer to your testing suite?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
> -config BLK_DEV_IDE_AT91
> - tristate "Atmel AT91 (SAM9, CAP9, AT572D940HF) IDE support"
> - depends on ARM && ARCH_AT91 && !ARCH_AT91RM9200 && !ARCH_AT91X40
> - select IDE_TIMINGS
> -
> config BLK_DEV_IDE_ICSIDE
> tristate &
ind if I send the usbhid dependency and the pen+multitouch
> series this week, or we are too close to the 3.9 opening window?
Please just send the patches, and let's see whether they will make it for
3.8 or I'll queue (some of) them for 3.9.
Thanks,
--
Jiri Kosina
SUSE Labs
--
T
if you'd
> rather wait for 3.10 :)
Yeah, sorry, my sentence was off-by-one, but I guess you got me :)
> Anyway, I'm doing my best to push them soon.
Thanks.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Wed, 6 Feb 2013, Heiko Carstens wrote:
> HID Sensors framework support (CONFIG_HID_SENSOR_HUB) unconditionally
> selects MFD_CORE which however depends on GENERIC_HARDIRQS.
> So add this dependency to HID_SENSOR_HUB as well.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
--
To unsubsc
etter choice.
>
> Signed-off-by: Benjamin Tissoires
Applied this one on top of the previous hid-multitouch patchset. Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
rent tree would be absolutely
sufficient).
Thanks.
--
Jiri Kosina
SUSE Labs
--
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 Wed, 27 Mar 2013, Jiri Kosina wrote:
> > I am looking at 3.9.rc1.
> > The only place I see the raw_event callback is called from
> > hid/hid_input_report(). hid_input_report is called with type
> > HID_INPUT_REPORT
> > in all cases, except hid_ctrl(), where it
gt; Fixes:
> https://bugzilla.redhat.com/show_bug.cgi?id=908604
>
> Reported-and-Tested-By: Clarke Wixon
> Signed-off-by: Benjamin Tissoires
> ---
>
> Hi Jiri,
>
> this one can goes to stable (so 3.8) as well.
Applied, and will push for 3.9 still.
Thanks.
--
Jiri
on my computer...
> And there is no point rebasing it on top of Linus' tree as the
> i2c_hid_request() callback is scheduled for 3.10.
>
> Could you double check Jiri?
Apologies, that was an error on my side, I have forgotten about the
i2c_hid_request()-related refactoring that is queue
e the new
> infrastructure.
>
> The file says:
> +# Sample syntax (see Documentation/kbuild/makefiles.txt for reference)
>
> But I did not bother to write this yet - awaiting feedback.
I generally like the idea.
It'd be nice to know whether this fixes the ARCH=sparc all
tions(-)
Thanks,
--
Jiri Kosina
SUSE Labs
--
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 Thu, 4 Apr 2013, Jiri Slaby wrote:
> In pointer_press_speed_show, we do
> data_pointer = hid_get_drvdata(hdev);
> twice in a row. Remove one of those.
>
> Signed-off-by: Jiri Slaby
> Cc: Jiri Kosina
> Cc: linux-in...@vger.kernel.org
> ---
> drivers/hid/hid
ly vaguely mentioning this
requirement in the changelog (and calling it recommendation), but make it
a hard prerequisity.
Without kernel addresses being invisible to userspace, this feature is
completely useless, but might provide very false sense of security if just
blindly enabled by random Joe B
On Mon, 14 Jan 2013, Steve Wise wrote:
> Reviewed-by: Steve Wise
Applied, thanks.
--
Jiri Kosina
SUSE Labs
--
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.
t;
> > I don't think it's strictly required, but it seems to work quite nicely
> > for other drivers as well.
>
> OK I'll wait a couple of days in-case any more comments come in and re-do
> the patch with the file name 'hid-steelseries.c' towards the end of
o
Simon,
thanks for respin of the patchset.
I thought we converged to hid-steelseries name in the end originally?
If you agree, I'll change it and apply.
--
Jiri Kosina
SUSE Labs
--
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/
ise we'll be corrupting
memory in steelseries_srws1_probe() here:
drv_data->led[SRWS1_NUMBER_LEDS] = led;
From: Jiri Kosina
Subject: [PATCH] HID: steelseries: fix out of bound array access
The last field of the driver_data->leds[] array is used to store the
special toggle for setting al
argument of i2c_hid_output_raw_report.
>
> Not removing the report_id from the given buffer adds this byte 2 times
> in the command, leading to a non working command.
>
> Reported-by: Andrew Duggan
> Signed-off-by: Benjamin Tissoires
Applied, will push it for 3.8 still. Than
,
by Nicholas Santos
Thanks.
Benjamin Tissoires (1):
HID: i2c-hid: fix i2c_hid_output_raw_report
Jiri Kosina (1):
HID: remove x bit from sensor doc
Nicholas Santos (1):
HID: usbhid: quirk for Formosa IR receiver
drivers/hid/hid-ids.h|3 +++
drivers/hid/i2c
@@ static struct hv_util_service util_kvp = {
> .util_deinit = hv_kvp_deinit,
> };
>
> +static void perform_shutdown(struct work_struct *dummy)
> +{
> + orderly_poweroff(true);
> +}
Is there any particular reason for this kind of crazy indentation?
--
Jiri K
On Wed, 23 Jan 2013, K. Y. Srinivasan wrote:
> Use the consolidated GUID definitions in the Hyper-V mouse driver.
>
> Signed-off-by: K. Y. Srinivasan
> Reviewed-by: Haiyang Zhang
Acked-by: Jiri Kosina
Greg, I guess you are taking this as a whole?
Thanks.
> ---
> driver
++
Is hid-srws1 really the best name? My understanding is that the vendor is
called Steelseries, and we mostly stick to calling the drivers according
to the device vendors (and grouping the quirks accordingly).
So how about hid-steelseries?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this lis
;
> - name_sz = strlen(hdev->uniq) + 15;
> + name_sz = strlen(hdev->uniq) + 16;
> +
> + /* 'ALL', for setting all LEDs simultaneously */
> + led = kzalloc(sizeof(struct led_classdev)+name_sz, GFP_KERNEL);
Is this memory ever freed?
--
Jiri Kosina
s vendor, we can
operatively decide on a different naming for the future.
> If you still would prefer a name change I can do that. In which case is
> the naming of the LED interfaces still OK?
>
> ie.
> --
> echo 1 > /sys/class/leds/SRWS1\:\:69005002125011007452\:
i2c-hid driver change into the series
>
> I still did not implemented the final usb cleanup for hid-multitouch as it may
> required few comments.
I have now taken the series. Thanks Benjamin, thanks Henrik.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "u
gt; bluetooth (and other transports) as well.
> >
> > Reported-by: Alexander Holler
> > Signed-off-by: Mika Westerberg
>
> Reviewed-By: Benjamin Tissoires
Applied.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
,
> + result = wait_event_timeout(i2c->queue,
> octeon_i2c_test_iflg(i2c),
> i2c->adap.timeout);
>
>
>
>
>
> [IMAGE]
>
> [SeenTimeChecker?do=5c4ee24ec3c4b5ef0b1e1d188d51662fbee53716e9d11aa47790d17410439b26f5961395f090d04f94a68828d2d0a0
gt; kernel interface.
> So we should cast this to 'unsigned long' before casting
> it to a pointer.
> Minimal fix, doesn't break anything which wasn't broken
> before.
>
> Cc: Jiri Kosina
> Signed-off-by: Hannes Reinecke
>
> diff --git a/drivers/m
NG might be
sufficient), but it is doable.
--
Jiri Kosina
SUSE Labs
--
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 Thu, 21 Feb 2013, David Howells wrote:
> The way we have come up with to get around this is to embed an X.509
> certificate containing the key in a section called ".keylist" in an EFI PE
> binary and then get the binary signed by Microsoft. The key can then be
> passed
> to the kernel by pass
s blacklisted.
In other words -- you blacklist the population of the key on systems by
blakclisting the key-carrying binary, but the key remains trusted on
whatever system the binary has been processed by keyctl before. Right?
If so, that's a clear difference from normal X.509 chain of trust (i
#x27;s not a permanent thing.
That unfortunately seems to be very weak security measure as well.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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/
by a key that has been blacklisted on the very
particular machine in its dbx is not going to work (as there is a very
direct x509 chain of trust link).
No?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
ke the blacklisting work properly, yes.
It of course still doesn't fix the principal problem, that you are
artificially changing the signature semantics of "Microsoft trusts this
binary" to "we claim that Microsoft actually meant that they trust this
key".
That has very li
On Sun, 17 Feb 2013, Paul Sbarra wrote:
> This is the original report descriptor as reported by lsusb -vd 046d:c294.
I have now applied both patches.
Paul, please try to provide more verbose changelogs in the future even for
such trivial changes as this.
Thanks.
--
Jiri Kosina
SUSE L
On Tue, 19 Feb 2013, Simon Wood wrote:
> This patch provides a modified report descriptor to split accelerator
> and brake, and adds the 'NO_GET' flag to prevent it hanging on
> connection.
Applied, thanks Simon.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this
of_platform_populate()
Jesper Dangaard Brouer (1):
percpu_counter.h: comment code for better readability
Jesper Juhl (3):
pcmcia: avoid static analysis complaint about use-after-free
net: mvneta: remove unneeded version.h include
IB: cxgb3: delay freeing mem untill entirely done with it
Jiri
dependency
Ian Abbott (1):
HID: blacklist Velleman data acquisition boards
Jiri Kosina (3):
HID: steelseries: rename driver to be compliant with other drivers
HID: steelseries: fix out of bound array access
HID: hidraw: print message when succesfully initialized
Mauro Carva
gh ... as long as it's
acked by appropriate maitaniners, patch monkey in re-transmission mode
works well.
--
Jiri Kosina
SUSE Labs
--
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
On Sun, 10 Mar 2013, Stefan Achatz wrote:
> Userland-tools now keep track of actual profile themselves.
> Spared out Pyra, which is a harder case.
Hi Stefan,
I fail to see how this is not breaking backwards compatibility?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: se
modules).
>
> The motherboard I use is Intel DP55KG which has the P55 Express
> chipset to control the USB.
>
> I've seen this behavior on the current kernel-3.8.x and also
> on the previous kernel-3.7. I have not tested anything earlier.
>
> Please CC to frank.pet
g.
>
> Can you try to do a git bisect for this? Is the sluggish system
> response clear enough that you can tell reliably when it is present and
> when it isn't?
That was my first thought, but unfortunately I am afraid there will be
point at which I will easily make a bi
IRC
> it was for OHCI rather than UHCI) which appeared to be related to
> activity on the built-in webcam.
Will check this. No external devices are plugged in, I think the only
internal one it has is bluetooth chip. I'll try turning it off.
--
Jiri Kosina
SUSE Labs
--
To unsubscr
On Thu, 14 Mar 2013, Jiri Kosina wrote:
> > Is occurrence of the "nobody cared" connected with any particular
> > device? Somebody reported a similar problem not long ago (although IIRC
> > it was for OHCI rather than UHCI) which appeared to be related to
> &g
On Thu, 14 Mar 2013, Jiri Kosina wrote:
> > > I don't think I have seen this message on rc1+ (8343bce, to be precise),
> > > but I have definitely seen sluggish system response on that kernel as
> > > well.
> > >
> > > Attaching lspci, /proc/i
t, we
> need to figure out why the fix may not be sufficient.
With either 4f535093cf or 181380b702 I do *not* see the problem, i.e.
these commits are not the culprit and it was caused by some later change.
I will proceed with bisect now, hopefully it'll produce a meaningful
result.
--
Jir
drm/i915: use the gmbus irq for waits
Adding Daniel, Imre and Daniel to CC while I will try to figure out what's
happening in parallel.
Attaching dmesg.txt from the machine with 28c70f162a as head, with
drm.debug=0xe.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send
On Fri, 15 Mar 2013, Jiri Kosina wrote:
> > I have the same problem on my Lenovo T500. I think the graphics card is
> > involved.
> >
> > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > Mobility Radeon HD 3650. When I boot with t
;
> Wasn't this fixed by the merge from David
> (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?
Why do you think it should, please?
(I am seeing this with a2362d247 still).
--
Jiri Kosina
SUSE Labs
--
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/
s fixed by the merge from David
> > > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?
> >
> > Why do you think it should, please?
>
> The line:
> - Fix PCH irq handling race which resulted in missed gmbus/dp
> aux irqs and subsequent fallout (Paul
ret = PER_LINUX;
> > > > + return ret;
> > > > +}
> > >
> > > Where did you get this from?
> > >
> > > You should not need compat_sys_personality, just call the native function.
> >
> > Hmm, but in that case an aarch32 application d
should be rather doing
set_personality(PER_LINUX | (current->personality & (~PER_MASK)))
otherwise you clobber the upper personality bits upon exec().
Something like the patch below. Either you can take it for tile, or I can
ask Andrew to fold it into my tree-wide fix cu
current->personality.
- as pointed out by Arnd Bergmann, PER_LINUX_32BIT is not used anywhere
by tile, so let's just drop that in favor of PER_LINUX
Signed-off-by: Jiri Kosina
Acked-by: Chris Metcalf
---
Andrew,
this is kind of followup to
cross-arch-dont-corrupt-personality-flags-upon-ex
onst
> struct hid_device_id *id)
> if (id->vendor == HID_ANY_ID && id->product == HID_ANY_ID)
> mt_post_parse_default_settings(td);
>
> - td->slots = kzalloc(td->maxcontacts * sizeof(struct mt_slot),
> - GFP_KERNEL);
> - if (!td->slots) {
> - dev_err(&hdev->dev, "cannot allocate multitouch slots\n");
> - hid_hw_stop(hdev);
> - ret = -ENOMEM;
> - goto fail;
> - }
> -
> ret = sysfs_create_group(&hdev->dev.kobj, &mt_attribute_group);
>
> mt_set_maxcontacts(hdev);
> @@ -774,7 +733,6 @@ static void mt_remove(struct hid_device *hdev)
> struct mt_device *td = hid_get_drvdata(hdev);
> sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group);
> hid_hw_stop(hdev);
> - kfree(td->slots);
> kfree(td);
> hid_set_drvdata(hdev, NULL);
> }
> @@ -1087,6 +1045,7 @@ static struct hid_driver mt_driver = {
> .remove = mt_remove,
> .input_mapping = mt_input_mapping,
> .input_mapped = mt_input_mapped,
> + .input_configured = mt_input_configured,
> .feature_mapping = mt_feature_mapping,
> .usage_table = mt_grabbed_usages,
> .event = mt_event,
> --
> 1.7.11.5
>
--
Jiri Kosina
SUSE Labs
--
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/
e.
Applying to apm.git, thanks Tejun.
--
Jiri Kosina
SUSE Labs
--
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/
me some more trouble in
the future ... :)
Well, I definitely have hardware back at home that supports this, so I can
take it. Doesn't seem to be heavy traffic code either.
Peter, ok with that? Also, how was this usually fed upstream -- through
Jens' tree?
--
Jiri Kosina
SUSE Labs
--
T
ces.
> It's now on the top of my TODO list.
Ah, I have missed the fact that this one is also part of Henrik's series,
sorry for the noise.
I haven't unfortunately reviewed the series yet due to kernel summit &
related events, but I'll get to it shortly.
Thanks,
--
Jir
from your series.
The remaining ones I am still about to review (currently travelling).
There is no inter-dependency between the Input and HID ones, and so we can
handle them with Dmitry as two independent Input and HID series, right?
Thanks a lot,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe fro
Well, your MTA didn't make it any better by not encoding it properly :)
I have fixed it manually and applied.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majord
On Fri, 3 Aug 2012, Masanari Iida wrote:
> Correct spelling typo in drivers/dma.
Applied.
--
Jiri Kosina
SUSE Labs
--
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://vg
citly enable this feature).
Thanks,
--
Jiri Kosina
SUSE Labs
--
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/
what is
loaded into cr3 in switch_mm()) is the same.
LKML is however very inappropriate list for such questions. Please ask on
kernelnewbies list next time.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
depends on USB_HID
select NEW_LEDS
select LEDS_CLASS
+ default HID_GENERIC
---help---
Support for the Lenovo ThinkPad USB Keyboard with TrackPoint.
That will fix the oldconfig issue and will not polute the
hid_have_special_driver[] by a rather ugly ifdef.
Thanks,
me different at that point ?
That is a different story. COW is applied on fork() (i.e. spawning new
process), not on clone(CLONE_VM) (i.e. spawning new thread).
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Unifying receivers full support"
> depends on HID_LOGITECH
> - default m
> ---help---
> Say Y if you want support for Logitech Unifying receivers and devices.
> Unifying receivers are capable of pairing up to 6 Logitech compliant
That was an overlook on my
an
either take the set through my tree with his Signed-off-by: on the Input
patches, or vice-versa.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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/
t; liberty to include now, I just fixed the changelog as was noticed that
> time to reference the right commit, and included my ack.
>
> Patch 5 and 6 implements earlier suggested cleanups and enhancements.
I have now finally got to reviewing the series and all the previous
Vivek's an
have just tested this v6 patchset (and it works for pktcddvd), only to
see that Kent has sent out v7 (unfortunately he hasn't CCed me on it).
v6 works nicely, bus as far as I understand it, even in v7 we are not
resetting bi_end_io and bi_private properly, right?
--
Jiri Kosina
SUSE Labs
-
ave now tested it and it works properly. You can add
Signed-off-by: Jiri Kosina
once you will be pushing the patchset through (I will be pushing
MAINTAINERS update through my tree to Jens separately).
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "uns
orkqueue inside the alloc_disk loop
floppy: do put_disk on current dr if blk_init_queue fails
floppy: properly handle failure on add_disk loop
floppy: use common function to check if floppies can be registered
floppy: remove dr, reuse drive on do_floppy_init
Jiri Kosina (1)
he bus, the copyright has
been blindly transfered into all the tiny drivers, which actually don't
contain any of Pauls' copyrighted code.
Remove the copyright from those sub-drivers.
Signed-off-by: Jiri Kosina
---
Paul,
I am sending this out to you as RFC, and am not willing to app
ersonality to PER_LINUX32 or PER_LINUX
> > discards any flags stored in the top three bytes
> >
> > Use personality() macro to compare only PER_MASK bytes and make sure that
> > we are setting only the bits that should be set, instead of
> > overwriting the whole value.
On Sun, 19 Aug 2012, Bruno Prémont wrote:
> This series fixes some race conditions in picoLCD driver during remove()
> and adds support for IR functionality.
I have now applied the series, thanks Bruno.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubs
non-Logitech devices using this usage page.
I am applying your patch now, but I guess we'll rather rename the define
in a near future.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
imes make debugging user-reported bugs a little bit
harder.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
On Mon, 4 Feb 2008, Jiri Kosina wrote:
> I still don't seem to fully understand what is happening here --
> aparently this is triggerable only with old programs linked against
> libc.so.5, and I am not able to trigger it with my trivial program when
> I link it against old
cess is
being established during loading of the binary, the beginning and the end
of the heap are the same ...
--
Jiri Kosina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel
libc.so.5-linked binaries on
any Fedora distro should trigger this bug ... (or you can use the binary
that Pavel supplied). Haven't tried this yet.
Thanks,
--
Jiri Kosina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
me from CC, thanks ]
Abel, I actually don't think you have chance to have any issues with
randomization, as the mentioned post talks about 2.6.22.10, which doesn't
randomize the brk start at all.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "u
es anyone have any comments regarding this patch please?
Still, it will probably not fix your particular program crashes, just
because it will always assume that brk starts immediately after the end of
the bss, which is plain wrong and has never been assured. Could you please
check whether ther
1 - 100 of 3548 matches
Mail list logo
