Yes, this driver is well past ready to be removed.
Acked-by: Doug Ledford
Sent from my ASUS Pad
Paul Gortmaker wrote:
>After getting warnings in an allyesconfig build[1] from this
>driver, I decided to remind myself just how old it was, and
>whether it warranted fixing. In the Kco
t Linux 7.0 days).
--
Doug Ledford
GPG KeyID: 0E572FDD
http://people.redhat.com/dledford
--
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.kern
On 08/12/2013 11:09 AM, Sasikantha Babu wrote:
> Kernel should not validate queue attributes default/ceiling value while
> creating a mqueue, if user pass attr as NULL. Otherwise In worst case
> If the validation fails then sys_mq_open returns -EINVAL/-EOVERFLOW
> which will make user clueless abou
On 08/12/2013 11:09 AM, Sasikantha Babu wrote:
> In the first patch since we removed calling mq_attr_ok to validate
> mqueue attributes default/ceil values, So removing the unused def_attr
>
> Signed-off-by: Sasikantha Babu
> ---
> ipc/mqueue.c |7 ---
> 1 files changed, 0 insertions(+),
?
>
> Given that, with user namespaces, it'll soon be possible for users who
> are unprivileged toward the host to be able to create and destroy
> namespaces, if the patch ends up making it easy for a user to consume a
> bunch of system time and not have it accounted at
in the ac
series kernels, but I don't know what happened to make it into 2.4.3. I'm
fixing one last known bug in the driver tonight, and when I'm done I'll put a
patch against 2.4.3 on my web site and drop a note here.
--
Doug Ledford <[EMAIL PROTECTED]> http://p
on my dell
> workstation (which has a need to have set explictely to a clocking of
> 41194 via ftsodell option), compiling without esd seems fix the prob
> for me.
The latest i810 driver does away with the ftsodell option entirely and should
work on your laptop without having to do any
scribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please chec
he code, so it
will take me a little bit to figure out where it is screwing up at.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe
Carlos Carvalho wrote:
>
> Doug Ledford ([EMAIL PROTECTED]) wrote on 9 February 2001 16:41:
> >The latest patch I sent Alan had both the hosts.c fix and some other fixes, so
> >I'm thinking it hasn't made it into his 2.2.19pre9 kernel. The next one
> >sho
Ville Herva wrote:
>
> On Thu, Feb 08, 2001 at 06:16:01PM +0200, you [Ville Herva] claimed:
> > On Thu, Feb 08, 2001 at 07:53:55AM -0500, you [Doug Ledford] claimed:
> > > Ville Herva wrote:
> > > >
> > > > It looks like ac6 (which I believe include
h your compiler, your fix in place, and then try to run
it on a PIII or later CPU and it will Oops all over the place. Run it on any
CPU that supports FXSAVE and it will likely blow chunks (all the Intel CPUs
will, but I don't know for sure about the AMD CPUs that support FXSAVE).
--
Doug
e correct test. However, the memory location in the fxsr structure was
reserved by the time the fxsr was put together, so the worst this does is give
an undefined mxcsr value on machines where mxcsr doesn't exist, which is why I
didn't yell too loudly when Linus dropped that line out
.
Sounds like an IRQ routing problem. Have you tried a UP kernel with IO-APIC
on UP support disabled or an SMP kernel both with and without the noapic
options to see if they make a difference?
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web
B/C SEEPROM
entry as needed. That should solve the problem anyway. Of course, it could
simply be something else that is wrong and I could be smoking crack ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updat
into
your own stuff so that we can keep a unified direction on this stuff.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
diff -U 3 -r linux-PIII-3/arch/
Andrea Arcangeli wrote:
>
> On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> > I've made a few correctness changes to this code. Items that needed to be
> > corrected for include the facts that the XMM feature bit is an Intel specific
> > bit that ot
Andrea Arcangeli wrote:
>
> On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> > @@ -214,8 +215,8 @@
> > movb ready,%al # First CPU if 0
> > orb %al,%al
> > jz 4f # First CPU skip this stuff
> > - m
Alan Cox wrote:
> 2.4.2-ac14
> o Updated i810_audio.c (Doug Ledford)
I wanted to let people know that there is a lot of new code in this particular
update that needs testing. The nice thing is that quake3 should now play with
this sound driver so the testi
ist. If that's not the case, and they list their
luns as all being connected, then this patch needs to go into the mainstream
kernel.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
Doug Ledford wrote:
> Patches welcomed. The one I sent already works on a fiber channel setup (the
> qla2x00 in question is fc and so is the Clariion array it's connected to, no
> detrimental side effects from scanning the box) and so I'm not inclined to add
> a REPORT LU
Pete Zaitcev wrote:
>
> > Date: Wed, 14 Mar 2001 21:28:14 -0500
> > From: Doug Ledford <[EMAIL PROTECTED]>
>
> > A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
> > sees multiple identical luns in different scenarios
that when I worked
> Why wait for a check condition? There's an INQUIRY field bit that
> indicates whether REPORT LUNs is supported.
And I'm all for using it in the 2.5 kernel SCSI stack ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please
ilities and
starts to confirm my position.
> Maybe someone can explain the meaning of the illegal
> requests at the end. Nevertheless, I can use the drive fine.
As to the illegal request messages, I'm not sure what those are about ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http:/
the problem you are referring to only
happens when a driver module is loaded prior to sd_mod.o, and that reversing
the order will solve the problem (but, I haven't looked so I could easily be
wrong ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Plea
d simply wait for the 2.5 development and debugging cycle?)
It would still be helpful because this problem has to be fixed before 2.5.
The only question is whether to fix it with a simple patch such as I just
submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
is h
c.patch.
Why would esd get a short write() unless it is opening the file in non
blocking mode (which I didn't see when I was working on the i810 sound
driver)? If esd is writing to a file in blocking mode and that write is
returning short, then that sounds like a driver bug to me.
--
n
a decent sound driver though, it shouldn't have to.
> -d
>
> Doug Ledford wrote:
>
> > David Ford wrote:
> > >
> > > Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
> > > writes to the socket without regard to re
is in need of killing sshd, I'll claim you are smoking some nice stuff ;-)
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe fro
al easy to reproduce too.
Take your favorite machine with lots of RAM, run just a handful of startup
process and system daemons, then log in on a few terminals and do:
while true; do bonnie -s (1/2 ram); done
Pretty soon, system daemons will start to die.
--
Doug Ledford <[EMAIL PROTECTED]&
Alan Cox wrote:
> o Next incarnation of the i810 audio driver (Doug Ledford)
Is this the i810 that's in Red Hat's CVS or the last copy of the big file that
I sent you? If it's the last copy of the big file I sent you, then it has a
memory leak that needs fixed. I
sn't need to.
To those people that would suggest I send in code I only have this to say.
Fine, I'll send in a patch to fix this bug. It will make the oom killer call
the cache reclaim functions and never kill anything. That would at least fix
the bug you see above.
--
really an oom killer, it's more like an "I'm Too Lazy To Free Up
Some More Pages So Now You Die" (ITLTFUSMPSNYD) killer.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
Mike Galbraith wrote:
>
> On Sat, 24 Mar 2001, Doug Ledford wrote:
> > To those people that would suggest I send in code I only have this to say.
> > Fine, I'll send in a patch to fix this bug. It will make the oom killer call
> > the cache reclaim functions and nev
tuations so I can test it here to see
if you are right?
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe from this list: send the line
Rik van Riel wrote:
>
> On Tue, 27 Mar 2001, Doug Ledford wrote:
>
> > I've been using our internal tree for my testing, and I'm reluctant to
> > let my experiences there cause me to draw conclusions about other
> > trees. So, will you please tell me whic
t CEOs actually pay attention
to how much distress IS is causing the rest of the company and give them a
swift kick in the ass to straighten things out (assuming you have a CEO worth
a damn, that assumption could be totally wrong).
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dled
equencer code). It resulting in invalid instructions getting
downloaded to every controller prior to a 7895. The attached patch should
solve people's problems with this. (Note, this patch wasn't made against a
full linux tree, so cd into driver/scsi and use patch -p1 in order to a
t; > The Linux 2.4.2-pre1 works fine. Next thing I was thinking was to try ac4
> > and also to try on a different machine which has a different revision of
> > the same type of aic7xxx HBA.
> >
>
> I am running ac5 on a AHA-2940U2/W, no problem.
>
> I patch
So, what this driver really needs is someone with a 7895 and someone with a
VLB/EISA controller to test it out. All the other controllers should be
working reliably at this point.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for ai
.2.1 driver because it limits your Quantum drive to 80MByte/s and that
particular speed doesn't include CRC checking. On this driver you have to be
running at 160MByte/s before CRC checking is enabled.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Plea
> >
> > I confirm that ac7 fixed all the aic7xxx problems on my machine.
Thanks, I hoped it would ;-) It's amazing what happens when you have a bcopy
in assembly that's missing the source address initialization :-(
--
Doug Ledford <[EMAIL PROTECTED]> http://peopl
-
>
> The machine waits "ad infinitum".
>
The latest patch I sent Alan had both the hosts.c fix and some other fixes, so
I'm thinking it hasn't made it into his 2.2.19pre9 kernel. The next one
should work fine as far as aic7xxx is concerned.
--
s,
they make an aggregate performance difference to the typical running of the
kernel (and this was without copy_page or zero_page being optimized, instead I
had done memset, memcpy, copy_*_user as optimized routines) and they make a
huge difference to benchmarks that target the areas they help the mos
Manfred Spraul wrote:
>
> Doug Ledford wrote:
> >
> > > I have this strong suspicion that your kernel will lock up in a bad way
> > > of you have somebody do something like divide by zero without actually
> > > touching a single FP instruction
San Jose, California 95129-1034
> +1 408 261-6630 | g g d r a s i l United States of America
> fax +1 408 261-6631 "Free Software For The Rest Of Us."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the
"Adam J. Richter" wrote:
>
> Doug Ledford wrote:
> >"Adam J. Richter" wrote:
>
> >> On the question of whether this is nothing more than
> >> aggregation,
>
> >Yes, on that very question, I would argue it is a mere aggr
an strace of amp seems to halt on writing to the /dev/dsp
>
> I have an Intel Celeron on an Asus-MEW motherboard which has this soundcard
> integrated.
>
> Any ideas?
Can you try xmms with the oss output module and tell me if that works?
--
Doug Ledford <[EMAIL PROTECTED]>
7;s a big part
of what makes it very fast, lots of room for driver optimizations and
enhanced feature support).
--
Doug Ledford <[EMAIL PROTECTED]>
http://people.redhat.com/dledford
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
atters." I
don't know why nVidia keeps their specs secret. All I know is what they
tell the world. But what I do know is that it's *possible* they could
be telling the truth, and I have no proof otherwise, regardless of any
suspicions.
--
Doug Ledford <[EMAIL PROTECTED]>
http:
e
benefits in terms of inter-processor bus pressure.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe from this list: send the line "u
he active path has already failed, which it doesn't currently
attempt to do when writing superblocks or reading partition tables).
> Is there any documentation about the changes in the SCSI-driver interfaces
> from 2.2 -> 2.4 (eg. in sd.c) ?
--
Doug Ledford <[EMAIL PROTECTED]&
"Eric Z. Ayers" wrote:
>
> Doug Ledford writes:
> (James Bottomley commented about the need for SCSI reservation kernel patches)
> >
> > I agree. It's something that needs fixed in general, your software needs it
> > as well, and I've written
Max TenEyck Woodbury wrote:
>
> Doug Ledford wrote:
> >
> > ...
> >
> > If told to hold a reservation, then resend your reservation request once every
> > 2 seconds (this actually has very minimal CPU/BUS usage and isn't as big a
> > deal as reque
capability could be plugged into this service so
> that users could reduce recoding depending on which fencing support they
> selected.
I wouldn't know about that.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx u
tware geared towards getting/holding reservations that also requires the
same kernel patches (plus one more to be fully functional, an ioctl to allow a
SCSI reservation to do a forced reboot of a machine). I'll be releasing that
package in the short term (once I get back from my vacation an
Max TenEyck Woodbury wrote:
>
> Doug Ledford wrote:
> >
> > Max TenEyck Woodbury wrote:
> >>
> >> Umm. Reboot? What do you think this is? Windoze?
> >
> > It's the *only* way to guarantee that the drive is never touched by more
> > than
failed writes on the primary path, I think this is of
dubious value. Right now, as I see it, multipath and failover simply don't
mix well. There is more work needed to make it work well.
> If this not any clearer than my last mail I will just wait to see the code
> :-).
>
&
now coming in on IRQ 10 and as a result,
things don't work.
Now, I'm all for blaming Intel BIOS bugs if they are the cause of the problem,
but I'm having a hard time seeing that here...
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please chec
worry about new PCI cards getting thrown
in, and yet we are remapping the IRQs. Why?
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To un
vulnerable to BIOS table bugs like this likely exposes, where as if you
didn't touch boot devices, then buggy BIOSes wouldn't bring your kernel to a
halt as easily.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx u
ly unlikely that there exists a
motherboard BIOS that *doesn't* at least assign the I/O space area and the IRQ
for all bootable devices on the system, regardless of PnPOS settings. Name
one concrete example of a motherboard BIOS that doesn't and I'll recant.
--
Doug Ledford <[EMA
s and variables via case.
> So I don't agree with (or understand) your objections. But I can certainly
> understand reluctance to merge a large-but-minor, do-nothing-much patch into
> a large and not-very-maintained driver.
Hehehe...and here I was thinking of factoring that t
if (bdev) {
> mutex_lock(&bdev->bd_inode->i_mutex);
> i_size_write(bdev->bd_inode, (loff_t)mddev->array_size
> << 10);
> mutex_unlock(&bdev->bd_inode->i_mutex);
> bdput(bdev);
> }
> }
> return rv;
> }
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
ch better if this module was simply dropped from the
> tree, as there will be lots of future patches that will break it.
>
I don't know that I would drop them, but certainly turn them off. They
can keep their driver up to date.
--
Doug Ledford GPG Key ID: 0E572FDD
Red Hat, Inc.
On 8/28/2016 2:06 AM, Leon Romanovsky wrote:
> On Fri, Aug 26, 2016 at 03:34:48PM -0400, Doug Ledford wrote:
>> On 8/26/2016 3:29 PM, Leon Romanovsky wrote:
>>> On Fri, Aug 26, 2016 at 02:01:55PM -0400, Doug Ledford wrote:
>>>> On 8/26/2016 9:35 AM, Doug Ledford wrot
On 8/27/2016 1:25 AM, Christophe JAILLET wrote:
> Le 26/08/2016 à 15:35, Doug Ledford a écrit :
>> On 8/26/2016 12:49 AM, Christophe JAILLET wrote:
>>> The 2nd parameter of 'find_first_bit' is the number of bits to search.
>>> In this case, we are passing '
is likely that the number of bits of 'tmp' was expected here. So use
> BITS_PER_LONG instead.
Thanks, applied.
--
Doug Ledford
GPG Key ID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
Shaia
>> Reviewed-by: Leon Romanovsky
>
> Ignore my comment on v2...
>
> Acked-by: Steve Wise
>
Thanks, applied.
--
Doug Ledford
GPG Key ID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
>
> diff --git a/drivers/infiniband/sw/Makefile b/drivers/infiniband/sw/Makefile
> index 8b095b27db87..988b6a0101a4 100644
> --- a/drivers/infiniband/sw/Makefile
> +++ b/drivers/infiniband/sw/Makefile
> @@ -1,2 +1 @@
> obj-$(CONFIG_INFINIBAND_RDMAVT) += rdmavt/
> -obj-$(CONFIG_RDMA_RXE) += rxe/
>
--
Doug Ledford
GPG Key ID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
On 8/8/2016 5:53 PM, Stephen Rothwell wrote:
> Hi Doug,
>
> On Mon, 8 Aug 2016 11:37:33 -0400 Doug Ledford wrote:
>>
>> On 8/7/2016 9:58 PM, Stephen Rothwell wrote:
>>>
>>> With Linus' tree, today's linux-next build (powerpc allyesconfig) failed
&
Again, this
>> change is NOT reflected in this patch-set.
>
> I can't apply this series to my tree because the hns infiniband driver
> doesn't exist in it.
>
No. This probably needs to go through my tree. Although with all of
the requirements, I'm a bit concerned about those being present elsewhere.
--
Doug Ledford
GPG Key ID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
;> added in
>>> ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again,
>> this
>>> change is NOT reflected in this patch-set.
>>
>> I can't apply this series to my tree because the hns infiniband driver
>> doesn't exist in it
On 8/25/2016 8:08 AM, Salil Mehta wrote:
>
>
>> -Original Message-----
>> From: Doug Ledford [mailto:dledf...@redhat.com]
>> Sent: Thursday, August 25, 2016 12:57 PM
>> To: David Miller; Salil Mehta
>> Cc: Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
&
th of these changes are already applied to my tree. However, if you
submit other changes to net-next and it starts generating merge
conflicts, you and the net team are going to get yelled at. If you are
going to have a shared driver, then you *HAVE* to work as a larger team
and plan your changes you submit to the linux kernel.
--
Doug Ledford
GPG Key ID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
> port_mask = be64_to_cpu(req->port_select_mask[3]);
> - port_num = find_first_bit((unsigned long *)&port_mask,
> - sizeof(port_mask));
> + port_num = find_first_bit((unsigned long *)&port_mask, 64);
>
> if (port_num != port) {
> pmp->mad_hdr.status |= IB_SMP_INVALID_FIELD;
>
--
Doug Ledford
GPG Key ID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
On 8/26/2016 12:49 AM, Christophe JAILLET wrote:
> In all other places in this file where 'find_first_bit' is called,
> port_num is defined as a 'u8' and no casting is done.
>
> Do the same here in order to be more consistent.
>
> Signed-off-by: Christophe
kfree(ah);
> > return ERR_PTR(-EINVAL);
> > + }
> > memcpy(ah->av.mac, dmac, ETH_ALEN);
> > }
> >
>
> Thank you for reviewing and fixing
Thanks, patch applied to -rc.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
er internal review that does nice small
> cleanup in many provider drivers that eliminates the check
> completely.
> Waiting for Moni to finish the review.
This sounds like a nice patch to push into for-next, but in the
meantime I took the V2 of this patch as it silences a checker w
On Sat, 2017-06-10 at 07:30 -0500, Steve Wise wrote:
> Acked-by: Steve Wise
Thanks, applied.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
gurable feature in
> hip08
> RDMA/hns: Update the IRRL table chunk size in hip08
> RDMA/hns: Update the PD&CQE&MTT specification in hip08
Thanks, applied.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Tue, 2017-10-24 at 03:28 -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list
> pointer to
> all timer callbacks, switch to using the new timer_setup() and
> from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Moni Shoua
>
; > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/infiniband/core/uverbs_std_types.c | 21 ++---
> > 1 file changed, 10 insertions(+), 11 deletions(-)
> >
>
> Thanks,
> Reviewed-by: Leon Romanovsky
Thanks, applied.
--
Doug Ledford
GPG KeyID
On Tue, 2017-11-07 at 08:45 -0600, Gustavo A. R. Silva wrote:
> Check on return value and goto label mbx_err are unnecessary.
>
> Addresses-Coverity-ID: 1268780
> Signed-off-by: Gustavo A. R. Silva
> Reviewed-by: Yuval Shaia
Thanks, applied.
--
Doug Ledford
GPG KeyID: B
n you weigh in on what you want in this thread? Thanks.
> >
>
> I am ok with both Colin's and Joe's patch.
>
> Joe's patch would require additional testing vs. the trivial warning fix.
>
> Then there is a "guideline" to keep fixes separate from clean
On Wed, 2017-10-11 at 14:41 +0200, Thomas Bogendoerfer wrote:
> Provide information about used firmware files via modinfo.
>
> Signed-off-by: Thomas Bogendoerfer
Thanks, applied.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274
On Tue, 2017-10-10 at 16:14 +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err error message
>
> Signed-off-by: Colin Ian King
Thanks, applied.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B
Bhumika Goyal
Acked-by: Doug Ledford
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
. Also removes an unused timer.
> >
> > Cc: Steve Wise
> > Cc: Doug Ledford
> > Cc: Sean Hefty
> > Cc: Hal Rosenstock
> > Cc: linux-r...@vger.kernel.org
> > Signed-off-by: Kees Cook
>
> Acked-by: Steve Wise
Thanks, applied.
--
Doug Ledford
GP
maining timers missed in the earlier i40iw patch.
>
> Cc: Faisal Latif
> Cc: Shiraz Saleem
> Cc: Doug Ledford
> Cc: Sean Hefty
> Cc: Hal Rosenstock
> Cc: linux-r...@vger.kernel.org
> Signed-off-by: Kees Cook
Thanks, applied.
--
Doug Ledford
GPG KeyID: B826A333
to
> .function, since .data will be going away.
>
> Cc: Mike Marciniszyn
> Cc: Dennis Dalessandro
> Cc: Doug Ledford
> Cc: Sean Hefty
> Cc: Hal Rosenstock
> Cc: linux-r...@vger.kernel.org
> Signed-off-by: Kees Cook
Thanks, applied.
--
Doug Ledford
GPG KeyID: B
already being called before the open-coded
> init_timer()
> and .data assignment. These are removed as well.
>
> Cc: Dennis Dalessandro
> Cc: Doug Ledford
> Cc: Sean Hefty
> Cc: Hal Rosenstock
> Cc: linux-r...@vger.kernel.org
> Signed-off-by: Kees Cook
T
icitly. Also removes an unused timer
> > and
> > drops a redundant initialization.
> >
> > Cc: Steve Wise
> > Cc: Doug Ledford
> > Cc: Sean Hefty
> > Cc: Hal Rosenstock
> > Cc: linux-r...@vger.kernel.org
> > Signed-off-by: Kees Cook
>
rt
> IB host channel adapter (model QHT7140),
>
The ipath driver was moved to staging/rdma/ipath and has proper
protection against being built without the InfiniBand subsystem. Where
are you seeing this tree? I'm curious because I no longer have this
driver in this location in my
On 09/01/2015 12:54 PM, Jim Davis wrote:
> On Tue, Sep 1, 2015 at 7:52 AM, Doug Ledford wrote:
>> On 09/01/2015 09:01 AM, Sudip Mukherjee wrote:
>>> building of ipath depends on infiniband. And if ipath is selected and
>>> infiniband is not then build fails with:
Signed-off-by: Jérôme Glisse
> cc:
> Cc: Haggai Eran
> Cc: Sagi Grimberg
> Cc: Shachar Raindel
> Cc: Doug Ledford
> ---
> drivers/infiniband/core/umem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/
->ufdev) {
> + usnic_err("Failed to alloc ufdev for %s\n", pci_name(dev));
> goto err_dealloc;
> }
>
>
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
zeof(*qp_flow), GFP_ATOMIC);
> - if (IS_ERR_OR_NULL(qp_flow)) {
> - err = qp_flow ? PTR_ERR(qp_flow) : -ENOMEM;
> + if (!qp_flow) {
> + err = -ENOMEM;
> goto out_dealloc_flow;
> }
> qp_flow->flow = flow;
>
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
o_be32(
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
d. See INIT_UDATA_BUF_OR_NULL().
>
> Awayway, I have patch to do the opposite, eg. explicitly cast u64 value
> to (void __user *)(unsigned long) in the caller function instead, as it
> allows some safer / new operations on the response buffer.
>
> Regards.
>
I haven't seen this oether patch that Yann is talking about, so I've
taken this one.
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
1 - 100 of 502 matches
Mail list logo
