n pgprot.
>
> Remove the NULL pointer check for the map. These functions return a valid
> address for valid pages and the return was bogus anyway as it would have
> left preemption and pagefaults disabled.
>
> Signed-off-by: Thomas Gleixner
> Cc: VMware Graphics
> Cc: Rola
The vmwgfx ones look all good to me, so for
23-53: Reviewed-by: Roland Scheidegger
That said, they were already signed off by Zack, so not sure what
happened here.
Roland
On 03.03.21 14:42, Lee Jones wrote:
> This is a resend. All of these patches have been sent before.
>
> The vm
hy it
ended up as a candidate for 5.8.
Roland
Am 12.10.20 um 15:30 schrieb Greg Kroah-Hartman:
> From: Zack Rusin
>
> [ Upstream commit f54c4442893b8dfbd3aff8e903c54dfff1aef990 ]
>
> ttm_mem_type_manager_func.get_node was changed to return -ENOSPC
> instead of setting t
interface v3), and at least I don't
see that one being backported to 5.8.
Roland
Am 05.10.20 um 16:44 schrieb Sasha Levin:
> From: Zack Rusin
>
> [ Upstream commit f54c4442893b8dfbd3aff8e903c54dfff1aef990 ]
>
> ttm_mem_type_manager_func.get_node was changed to return -ENOSPC
>
I'm now able to reproduce this, looking into it. (The crash looks
actually similar to what was also happening with the next commit,
drm/ttm: make TT creation purely optional v3, but that got reverted
already.)
Roland
Am 19.08.20 um 09:47 schrieb 허종만:
>
> Hi,
>
>
> I'
Thanks, I've put the fix in the vmwgfx-next branch.
Roland
Am 10.08.20 um 12:04 schrieb Colin King:
> From: Colin Ian King
>
> There is a spelling mistake in a DRM_ERROR message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.
I've commited this to our next branch, thanks!
(I'm actually kind of impressed this can be found automatically...)
Roland
Am 17.06.20 um 23:51 schrieb Gustavo A. R. Silva:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potenti
I've pulled that into our tree, thanks!
Roland
Am 07.05.20 um 13:07 schrieb Jason Yan:
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:518:9-10: WARNING: return of 0/1
> in function 'vmw_fence_obj_signaled' with return type bool
&g
I'm not exactly an expert on this, but looks alright to me.
Acked-by: Roland Scheidegger
Am 05.05.20 um 10:46 schrieb Marek Szyprowski:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> su
STCheck written by us.
>
> Signed-off-by: Jia-Ju Bai
Reviewed-by: Roland Kammerer
4 files changed, 5 insertions(+), 4 deletions(-)
>
Hi Gustavo,
as also discussed with Lars in person, obviously OK for the DRBD part.
Acked-by: Roland Kammerer
Best, rck
6 TSC is wider than HPET but
there may be other architectures that could hit the same problem, just
with the clocksource being checked wrapping around instead of the
watchdog clocksource. Right?
Thanks!
Roland
Commit-ID: d999c0ec2498e54b9328db6b2c1037710025add1
Gitweb: https://git.kernel.org/tip/d999c0ec2498e54b9328db6b2c1037710025add1
Author: Roland Dreier
AuthorDate: Fri, 30 Nov 2018 13:14:50 -0800
Committer: Borislav Petkov
CommitDate: Tue, 4 Dec 2018 12:17:21 +0100
x86/hpet: Remove
The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23
("x86: hpet: Cleanup the clockevents init and register code").
Signed-off-by: Roland Dreier
---
arch/x86/kernel/hpet.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker
le leaving detection of true
instability very likely within a few clocksource watchdog iterations.
Signed-off-by: Roland Dreier
---
kernel/time/clocksource.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksour
The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23
("x86: hpet: Cleanup the clockevents init and register code").
Signed-off-by: Roland Dreier
---
arch/x86/kernel/hpet.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker
can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
> The sensible thing to do in nvme is to use different paths for
> different queues. That is e.g. in the RDMA case use the HCA closer
> to a given CPU by default. We might allow to override this for
> cases where the is a good reason, but what I really don't want is
> configurability for configur
> Moreover, I also wanted to point out that fabrics array vendors are
> building products that rely on standard nvme multipathing (and probably
> multipathing over dispersed namespaces as well), and keeping a knob that
> will keep nvme users with dm-multipath will probably not help them
> educate t
> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next
> (next-20180511). Here's a simplified reproducer:
Thanks! That's a fantastic test case.
The issue is a race where rdma_listen() sees invalid state in the
middle of an rdma_bind_addr() call that will ultimately fail.
On Tue, Apr 24, 2018 at 03:14:10PM +0200, Luc Van Oostenryck wrote:
> print_st_err() is defined with its 4th argument taking an
> 'enum drbd_state_rv' but its prototype use an int for it.
>
> Fix this by using 'enum drbd_state_rv' in the prototype too.
>
> Signed-off-by: Luc Van Oostenryck
> ---
On Wed, Oct 04, 2017 at 09:33:18AM +0800, Jia-Ju Bai wrote:
> The driver may sleep under a RCU lock, and the function call path is:
> drbd_sync_handshake (acquire the RCU lock)
> drbd_asb_recover_1p
> drbd_khelper
> drbd_bcast_event
> genlmsg_new(GFP_NOIO) --> may sleep
>
> To
> Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport
> protocol for transferring upper layer (SMB2) payload over RDMA via
> Infiniband, RoCE or iWARP. The prococol is published in [MS-SMBD]
> (https://msdn.microsoft.com/en-us/library/hh536346.aspx).
This is great to see.
On Thu, Jul 06, 2017 at 08:02:41PM +0200, Greg KH wrote:
> On Thu, Jul 06, 2017 at 07:56:07PM +0200, Roland Kammerer wrote:
> > On Mon, Jun 05, 2017 at 11:26:23AM +0200, Greg KH wrote:
> > > From: Greg Kroah-Hartman
> > >
> > > Nothing like having a very gene
ued it up in our out-of-tree repo.
>
> Note, there are many other "generic" named global variables in the drbd
> subsystem, someone should fix those up one day before they hit a linking
> error.
Did that as well.
Both should hit some merge-window soon.
Thanks, rc
294,7 @@ static bool conn_ov_running(struct drbd_connection
> *connection)
> static enum drbd_ret_code
> check_net_options(struct drbd_connection *connection, struct net_conf
> *new_net_conf)
> {
> - static enum drbd_ret_code rv;
> + enum drbd_ret_code rv;
> struct drbd_peer_device *peer_device;
> int i;
Yes, that already got dropped for drbd9 and is obviously correct for
in-tree drbd8.
Signed-off-by: Roland Kammerer
Regards, rck
rectly because the TSC would change).
(And I'd guess better avoid an armed deadline timer while changing
TSC_ADJ...)
In any case, I've tested the two patches on top of x86-timers and they
work just fine - all TSC_ADJ values get set to zero both on boot and
resume, no lockups, and tsc clocks
Am 13.12.2016 um 17:46 schrieb Thomas Gleixner:
> On Tue, 13 Dec 2016, Roland Scheidegger wrote:
>
>> Am 13.12.2016 um 14:14 schrieb Thomas Gleixner:
>>> Roland reported interesting TSC ADJUST register wreckage on his DELL
>>> machine, which seems to populate
Am 13.12.2016 um 14:14 schrieb Thomas Gleixner:
> Roland reported interesting TSC ADJUST register wreckage on his DELL
> machine, which seems to populate that MSR with a random number generator.
FWIW, I thought about the actual values some more and I don't actually
think they are all
Am 10.12.2016 um 02:55 schrieb Roland Scheidegger:
> Am 09.12.2016 um 23:59 schrieb Thomas Gleixner:
>> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>>
>> Cc'ed someone from Dell.
>>
>>> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner:
>>>> C
Am 09.12.2016 um 23:59 schrieb Thomas Gleixner:
> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>
> Cc'ed someone from Dell.
>
>> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner:
>>> Can you add the patch below to gather more information? There is a hunk in
>
Am 09.12.2016 um 18:33 schrieb Thomas Gleixner:
> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>> Am 09.12.2016 um 10:59 schrieb Thomas Gleixner:
>>> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>>>>
>>>> I saw some system lockups though:
>>>>
Am 09.12.2016 um 10:59 schrieb Thomas Gleixner:
> On Fri, 9 Dec 2016, Roland Scheidegger wrote:
>>
>> I saw some system lockups though:
>> When doing a cold boot, this kernel never managed to boot up. The last
>> message seen is:
>> x86: Booting SMP configuration:
On 08/31/16 22:06, Roland Singer wrote:
> Here is Peter Wu's reply, which was not send to the mailing list, because
> I had to resend my e-mail to him due to a failure...
>
>
> Forwarded Message
> Subject: Re: Fwd: Re: Kernel Freeze with American Megatren
Here is Peter Wu's reply, which was not send to the mailing list, because
I had to resend my e-mail to him due to a failure...
Forwarded Message
Subject: Re: Fwd: Re: Kernel Freeze with American Megatrends BIOS
Date: Wed, 31 Aug 2016 18:08:53 +0200
From: Peter Wu
To: R
>>
>> Thanks. Right now I am overriding the DSDT, but I am not able to override
>> the SSDT, because I have to fix and compile all the SSDT files. There
>> are too many compile errors... Wanted to find the exact line which
>> is responsible for the hickup.
>
> Have you disassembled with externs in
Am 31.08.2016 um 13:46 schrieb Peter Wu:
> On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
>> Am 30.08.2016 um 21:53 schrieb Peter Wu:
>>> On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
>>>> [+cc linux-acpi, linux-kernel, dri-devel]
&g
Am 30.08.2016 um 21:53 schrieb Peter Wu:
> On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
>> [+cc linux-acpi, linux-kernel, dri-devel]
>>
>> Hi Roland,
>>
>> I have no idea how to debug this problem. Are you seeing something
>> that sugge
Am 30.08.2016 um 21:21 schrieb Peter Wu:
> On Tue, Aug 30, 2016 at 02:13:46PM -0400, Ilia Mirkin wrote:
>> On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer
>> wrote:
>>> I configured bbswitch to not set any states automatically...
>>> So it's possible to
Am 30.08.2016 um 20:13 schrieb Ilia Mirkin:
> On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer
> wrote:
>> I configured bbswitch to not set any states automatically...
>> So it's possible to obtain and verify the GPU power state.
>>
>> However I removed the bbsw
Am 30.08.2016 um 20:09 schrieb Emil Velikov:
> I second Ilia here. Using bbswitch in conjunction with any driver (be
> that nouveau or the proprietary one) is a bad idea.
>
I removed bbswitch from my system and will use vgaswitcheroo to check
the GPU power state from now.
> (If Ilia's suggestions
Same log messages as send before.
Am 30.08.2016 um 19:43 schrieb Ilia Mirkin:
> On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer
> wrote:
>> My conclusion:
>>
>> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs.
>>I would love to help her
11 but other things break...
What the hell is going on?! :/
Am 30.08.2016 um 17:48 schrieb Emil Velikov:
> On 30 August 2016 at 16:25, Roland Singer wrote:
>> I tried these scenarios:
>>
>> 1. Booted the system without the bbswitch module. The nouveau module
>>wa
, then it is not the video driver nor bbswitch.
Am 30.08.2016 um 16:08 schrieb Emil Velikov:
> On 30 August 2016 at 14:06, Bjorn Helgaas wrote:
>> On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote:
>>> Thanks for pointing it out.
>>>
>>> Yeah that'
ght be the trigger.
Any hints how to continue debugging?
Cheers,
Roland
Am 30.08.2016 um 01:54 schrieb Bjorn Helgaas:
> On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote:
>> Just tried it and the system didn't freeze. However it will freeze
>> after some ti
Just tried it and the system didn't freeze. However it will freeze
after some time (few minutes while working).
Seams to be pci_read_config_dword. Where is this exactly defined?
Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
> On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrot
//github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
> [+cc linux-acpi, linux-kernel, dri-devel]
>
> Hi Roland,
>
> I have no idea how to debug this problem. Are you seeing something
> that suggests it may be a PCI
On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe
wrote:
> So, it appears, the dst and neigh can be used for all performances cases.
>
> For the non performance dst == null case, can we just burn cycles and
> stuff the daddr in front of the packet at hardheader time, even if we
> have to copy?
OK,
On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe
wrote:
> We have neighbour_priv, and ndo_neigh_construct/destruct now ..
>
> A first blush that would seem to be enough to let ipoib store the AH
> and other path information in the neigh and avoid the cb? At least the
> example in clip sure looks li
>> struct skb_gso_cb {
>> int mac_offset;
>> int encap_level;
>> __u16 csum_start;
>> };
> This is based on an out-dated version of this struct. The 4.7 RC
> kernel has a few more fields that were added to support local checksum
> offload for encapsulated frames.
On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote:
> Or just shift GSO CB and add couple checks like
> BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb)));
Resurrecting this old thread, because the patch that ultimately went
upstream (commit 9207f9d45b0a / net: preserve IP
From: Roland Dreier
On a system with an Intel PCIe port configured as an NTB device, iommu
initialization fails with
DMAR: Device scope type does not match for :80:03.0
This is because the DMAR table reports this device as having scope 2
(ACPI_DMAR_SCOPE_TYPE_BRIDGE):
[0A0h 0160
On Tue, May 31, 2016 at 3:31 PM, Rafael J. Wysocki wrote:
> It may not be called at all if _PTC is used on that system, for example.
Yes, that's exactly the case on my system.
So from my POV:
Tested-by: Roland Dreier
Thanks!
On Tue, May 31, 2016 at 2:11 PM, Rafael J. Wysocki wrote:
> Can you please try the appended patch (untested)?
Thanks for the quick reply. Patch looks OK on my system... it boots
(which is very good :) and I see
system 00:01: [io 0x0400-0x047f] has been reserved
however I don't see the "AC
d long-term
solution. Does it make sense to resurrect the patches you had to let
ACPI and PnP coexist in resource reservation? Or could we move the
request_region() for CPU throttle into the still-modular
initialization done from acpi_processor_driver_init()?
Thanks!
Roland
On Mon, Oct 19, 2015 at 10:00 AM, Yinghai Lu wrote:
> I would suggest to expand standard_io_resources[] to include all
> possible conflict that we should avoid, like the io port for serial and
> cf8/cf9.
>
> Then we could just set PCIBIOS_MIN_IO to 0 for x86.
That would work on my system, which
nce of ACPI in the real world) is this
a broken BIOS change that I should ask my BIOS vendor to revert?
Or... ?
Thanks!
Roland
--
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:
WE OFFER LOAN AT 3% INTEREST RATE
--
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/
WE OFFER LOAN AT 3% INTEREST RATE
--
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, Jul 21, 2015 at 1:57 AM, Sagi Grimberg wrote:
> How were you able to get a chained SG list in the target code?
Local hack. So this bug can't be hit in current mainline code, but
patch improves the code and removes a hidden booby-trap, so I think it
makes sense to apply.
--
To unsubscribe
On Sat, Jun 13, 2015 at 9:56 AM, Roland Dreier wrote:
> Below is a more sophisticated, so to speak, version of it with a changelog and
> all. It works for me, but more testing would be much appreciated.
Yes, the patch works as expected:
Tested-by: Roland Dreier
It does change /proc/i
building 3.10.80 patched with this (needed a tiny bit of context
adjustment because acpi_dev_filter_resource_type() hadn't been added
to 3.10 yet), and will confirm that it fixes the issue I saw.
Thanks!
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
On Thu, Jun 11, 2015 at 1:50 PM, Rafael J. Wysocki wrote:
> Changing the ordering between those two routines would work around that
> problem,
> but in my view that wouldn't be a proper fix. In fact, the role of
> reserve_range()
> is to reserve the resources so as to prevent them from being us
On Wed, Jun 10, 2015 at 4:23 PM, Rafael J. Wysocki wrote:
> Can you please file a bug at bugzilla.kernel.org to track this and attach
> the output of acpidump from the affected system in there?
Done: https://bugzilla.kernel.org/show_bug.cgi?id=99831
Thanks!
--
To unsubscribe from this list: send
On Tue, Jun 9, 2015 at 4:43 PM, Roland Dreier wrote:
> I understand that the change here fixed another regression, but I'm
> wondering if there's a way to make everyone happy here? I can provide
> debugging info from my system as required...
Maybe sent my mail too quic
0820-0x0827]
We're able to reserve the range, and then PCI assigns ahci into a
non-conflicting range.
I understand that the change here fixed another regression, but I'm
wondering if there's a way to make everyone happy here? I can provide
debugging info from my system as required...
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
InfiniBand/RDMA updates for 4.1:
- IPoIB fixes from Doug Ledford and Erez Shitrit
- iSER updates from Sagi
On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe
wrote:
>> We can give client->add() callback a return value and make
>> ib_register_device() return -ENOMEM when it failed, just wondering
>> why we don't do this at first, any special reason?
> No idea, but having ib_register_device fail and unwin
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
One 4.0 RDMA change:
- Fix for exploitable integer overflow in uverbs interface
The input file name should be set after parse_options has been called if
the '-i' option is to have any effect.
Signed-off-by: Roland Grunberg
---
Not registered to the referenced lists so feel free to CC.
The input file option for perf-annotate seems to be broken and will always
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
InfiniBand/RDMA changes for 3.20 merge window:
- Re-enable on-demand paging changes with stable ABI
- Fairly
On Tue, Feb 17, 2015 at 6:32 PM, Stephen Rothwell wrote:
> After merging the livepatching tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0:
> drivers/infiniband/hw/qib/qib.h: In function 'qib_flush_wc':
> dr
h so that it doesn't add crazy stuff like
(enum dma_data_direction)PCI_DMA_BIDIRECTIONAL
and resend the change.
Thanks,
Roland
--
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/
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
One more last-second RDMA change for 3.19:
- Yann realized that the previous revert of new userspace ABI did
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
Last minute InfiniBand/RDMA changes for 3.19:
- Revert IPoIB driver back to 3.18 state. We had a number of
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
Main batch of InfiniBand/RDMA changes for 3.19:
- On-demand paging support in core midlayer and mlx5 driver
On Mon, Dec 15, 2014 at 5:56 PM, Roland Dreier wrote:
> I'll add a partial revert of that patch to my tree to get back the
> now-used enum values.
I rebased my tree on top of the merge-window merge of davem's tree,
and added the missing flag on top of the "remove this flag&
On Mon, Dec 15, 2014 at 5:47 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the infiniband tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_query_device':
> drivers/infiniband/hw/mlx5/main.c:248:34: error:
Not that I'm actually involved any more, but I'd endorse the user_regset
approach and not the new request. On many (most?) machines, it's already
part of the main integer regset (orig_rax et al) and adding another
mechanism is redundant. Using user_regset also means there won't be a word
of hidde
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
Main set of InfiniBand/RDMA updates for 3.18 merge window:
- Large set of iSER initiator improvements
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
This is later and bigger than I would like, and the blame is all on
me: I got very busy with other stuff for a few weeks during the 3.17
cycle, and didn't prepare this tr
This patch adds DT support for leds-pca9532.
Signed-off-by: Roland Stigge
---
Applies to v3.17-rc4
v3: Removed superfluous whitespace
v2: Removed #ifdef statements
Documentation/devicetree/bindings/leds/leds-pca9532.txt | 43 ++
drivers/leds/leds-pca9532.c
s probably enough to
> leave this used by the LED subsystem.
Right, this PWM is really only intended for LED use (as already done w/o
DT).
Sending the updated patch.
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
This patch adds DT support for leds-pca9532.
Signed-off-by: Roland Stigge
---
Applies to v3.17-rc4
v2: Removed #ifdef statements
Documentation/devicetree/bindings/leds/leds-pca9532.txt | 43 ++
drivers/leds/leds-pca9532.c | 47
2
This patch adds DT support for leds-pca9532.
Signed-off-by: Roland Stigge
---
Applies to v3.17-rc4
Documentation/devicetree/bindings/leds/leds-pca9532.txt | 43 ++
drivers/leds/leds-pca9532.c | 47
2 files changed, 90 insertions
This patch fixes an error message typo ("not" missing).
Signed-off-by: Roland Stigge
---
drivers/spi/spi-pl022.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2136,7 +2136,7 @@ static int pl022_probe(struct
> I would like to note that we at Los Alamos National Laboratory are very
> interested in this functionality and it would be great if it gets accepted.
Have you done any review or testing of these changes? If so can you
share the results?
- R.
--
To unsubscribe from this list: send the line "un
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
Main set of InfiniBand/RDMA updates for 3.17 merge window:
- MR reregistration support
- MAD support for
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
InfiniBand/RDMA fixes for 3.16
- cxgb4 hardware driver regression fixes
- mlx5 hardware driver regression
That's OK with me. But I'm not really actively involved in kernel
maintenance any more (though happy to answer anything Oleg wants advice on).
Acked-By: Roland McGrath
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
Main batch of InfiniBand/RDMA changes for 3.16:
- Add iWARP port mapper to avoid conflicts between RDMA and
Hi nice to meet you . I'm Ms Laura Roland from Switzerland, is a pleasure to
contact you today,please write me back . thanks from Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordom
p track of how many requests are in-flight and
delay writing the next output, until the previous one has completed.
Question back to the community: are there APIs in the USB layer to check
for presence of in-progress requests? Can one add a 'completion'
callback to a request, that gets invok
ates and sending USB
updates, as well as a device-specific layer to "calibrate" and "unify"
the force responses across different models.
Does this make sense?
thanks
roland
--
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/
the 'game'. I don't think
this is currently the case with today's drivers. I was able to send
force updates to a gamepad faster than the USB update rate, which led to
some lost packets which in turn left the device in a inconsistent state
- the motors were still rumbling although
itional effects with constant force.
>>
>> Thank you for the explanation. This further solidifies for me the idea
>> that handling of such effects that are in fact uploaded to and managed
>> by the device should not be handled by the memoryless core but rather by
>> the driver
1 - 100 of 1885 matches
Mail list logo
