the card side.
>
> We are IBM :-) So far, it seems to be that the card is doing something
> not quite right, but we don't know what. We might need to engage
> Mellanox themselves.
Possibly. On the other hand, I've had it reported that this is a
software regression at least
On Thu, Dec 06, 2018 at 08:45:09AM +0200, Leon Romanovsky wrote:
> On Thu, Dec 06, 2018 at 03:19:51PM +1100, David Gibson wrote:
> > Mellanox ConnectX-5 IB cards (MT27800) seem to cause a call trace when
> > unbound from their regular driver and attached to vfio-pci in order t
nging any
> behavior), and 2) add the ConnectX devices to the quirk. That way
> the ConnectX change is smaller and more easily
> understood/reverted/etc.
Sure. Would it make sense to send (1) as an independent cleanup,
while I'm still working out exactly what (if anything)
On Thu, Dec 06, 2018 at 08:45:09AM +0200, Leon Romanovsky wrote:
> On Thu, Dec 06, 2018 at 03:19:51PM +1100, David Gibson wrote:
> > Mellanox ConnectX-5 IB cards (MT27800) seem to cause a call trace when
> > unbound from their regular driver and attached to vfio-pci in order t
that more permanently,
use a device quirk to disable D3 state for these devices.
We do this by renaming the existing quirk_no_ata_d3() more generally and
attaching it to the ConnectX-[45] devices (0x15b3:0x1013).
Signed-off-by: David Gibson
---
drivers/pci/quirks.c | 17 +++--
1
an <= in ibmveth_change_mtu(), which only permits an MTU which
is strictly smaller than the buffer size, rather than allowing the buffer
to be completely filled.
This patch fixes the buglet.
Signed-off-by: David Gibson
Acked-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmveth.c | 4 ++--
1 file
nging the dts
files.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
To unsubscribe from this list: se
On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> > It occurred to me the other day. Instead of using a new "unused"
> > property for this, should we be using the OF standard "
to still expose them (since their registers
> are present in the MMIO space) but with an "unused" property in
> them.
It occurred to me the other day. Instead of using a new "unused"
property for this, should we be using the OF standard "status"
property.
--
Dav
t;[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozla
of course.
>
> > Correct fix is just to remove EMAC_MR1_MF_1000GPCS from the first
> > if condition.
>
> Yep.
>
> > I'll send correct fix shortly along with other queued patches.
>
> Thanks.
I've merged essentially the same fix into the devi
id orinoco_unlock(struct orinoco_private *priv,
> unsigned long *flags)
> {
> spin_unlock_irqrestore(&priv->lock, *flags);
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | m
in <[EMAIL PROTECTED]>
All look good to me.
Acked-by: David Gibson <[EMAIL PROTECTED]>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _a
13 matches
Mail list logo
