aligned skb and appending the remainder using
skb_add_rx_frag(). The kernel network stack only cares about the
headers, so the alignment of the packet payload doesn't matter.
--
Måns Rullgård
b_add_rx_frag(). The kernel network stack only cares about the
headers, so the alignment of the packet payload doesn't matter.
--
Måns Rullgård
ment that A) solves this.
Driver-specific interfaces are not the solution. That way lies chaos
and madness.
This would all be so much easier if you all would just shut up for a
moment and let me fix it properly.
--
Måns Rullgård
.
Driver-specific interfaces are not the solution. That way lies chaos
and madness.
This would all be so much easier if you all would just shut up for a
moment and let me fix it properly.
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 09/12/16 07:59, Vinod Koul wrote:
>> On Thu, Dec 08, 2016 at 04:48:18PM +, Måns Rullgård wrote:
>>> Vinod Koul <vinod.k...@intel.com> writes:
>>>
>>>> To make it efficient, disregarding your S
Sebastian Frias writes:
> On 09/12/16 07:59, Vinod Koul wrote:
>> On Thu, Dec 08, 2016 at 04:48:18PM +0000, Måns Rullgård wrote:
>>> Vinod Koul writes:
>>>
>>>> To make it efficient, disregarding your Sbox HW issue, the solution is
>>>>
lers request lines are hard wired so they cant use any channel. But
> if you dont have this restriction then driver can queue up many transactions
> from different controllers.
Have you been paying attention at all? This exactly what the driver
ALREADY DOES.
--
Måns Rullgård
ard wired so they cant use any channel. But
> if you dont have this restriction then driver can queue up many transactions
> from different controllers.
Have you been paying attention at all? This exactly what the driver
ALREADY DOES.
--
Måns Rullgård
Vinod Koul <vinod.k...@intel.com> writes:
> On Thu, Dec 08, 2016 at 11:44:53AM +0000, Måns Rullgård wrote:
>> Vinod Koul <vinod.k...@intel.com> writes:
>>
>> > On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>> >> Vinod Koul <
Vinod Koul writes:
> On Thu, Dec 08, 2016 at 11:44:53AM +0000, Måns Rullgård wrote:
>> Vinod Koul writes:
>>
>> > On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>> >> Vinod Koul writes:
>> >>
>> >> >
Vinod Koul <vinod.k...@intel.com> writes:
> On Thu, Dec 08, 2016 at 12:20:30PM +0000, Måns Rullgård wrote:
>> >
>> > I'm far from claiming that drivers/tty/serial/sh-sci.c is perfect, but
>> > it does request DMA channels at open time, not at probe time.
>
Vinod Koul writes:
> On Thu, Dec 08, 2016 at 12:20:30PM +0000, Måns Rullgård wrote:
>> >
>> > I'm far from claiming that drivers/tty/serial/sh-sci.c is perfect, but
>> > it does request DMA channels at open time, not at probe time.
>>
>> In the part quo
Mason <slash@free.fr> writes:
> On 08/12/2016 13:44, Måns Rullgård wrote:
>
>> Mason <slash@free.fr> writes:
>>
>>> On 08/12/2016 13:20, Måns Rullgård wrote:
>>>
>>>> The only problem we have is that nobody envisioned hardware
Mason writes:
> On 08/12/2016 13:44, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 08/12/2016 13:20, Måns Rullgård wrote:
>>>
>>>> The only problem we have is that nobody envisioned hardware where the
>>>> dma engine indicates
Mason <slash@free.fr> writes:
> On 08/12/2016 13:20, Måns Rullgård wrote:
>
>> The only problem we have is that nobody envisioned hardware where the
>> dma engine indicates completion slightly too soon. I suspect there's a
>> fifo or such somewhere, and t
Mason writes:
> On 08/12/2016 13:20, Måns Rullgård wrote:
>
>> The only problem we have is that nobody envisioned hardware where the
>> dma engine indicates completion slightly too soon. I suspect there's a
>> fifo or such somewhere, and the interrupt is triggered when t
Geert Uytterhoeven <ge...@linux-m68k.org> writes:
> Hi Måns,
>
> On Thu, Dec 8, 2016 at 12:47 PM, Måns Rullgård <m...@mansr.com> wrote:
>> Geert Uytterhoeven <ge...@linux-m68k.org> writes:
>>> On Thu, Dec 8, 2016 at 11:54 AM, Mason <slash@free.fr
Geert Uytterhoeven writes:
> Hi Måns,
>
> On Thu, Dec 8, 2016 at 12:47 PM, Måns Rullgård wrote:
>> Geert Uytterhoeven writes:
>>> On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote:
>>>> On 08/12/2016 11:39, Vinod Koul wrote:
>>>>> On Wed, De
Geert Uytterhoeven <ge...@linux-m68k.org> writes:
> On Thu, Dec 8, 2016 at 12:44 PM, Måns Rullgård <m...@mansr.com> wrote:
>> Vinod Koul <vinod.k...@intel.com> writes:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>>>> Vinod K
Geert Uytterhoeven writes:
> On Thu, Dec 8, 2016 at 12:44 PM, Måns Rullgård wrote:
>> Vinod Koul writes:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>>>> Vinod Koul writes:
>>>> > On Tue, Dec 06, 2016 at 01:14:20PM +,
Geert Uytterhoeven <ge...@linux-m68k.org> writes:
> On Thu, Dec 8, 2016 at 11:54 AM, Mason <slash@free.fr> wrote:
>> On 08/12/2016 11:39, Vinod Koul wrote:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>>>> Vinod Koul <vinod
Geert Uytterhoeven writes:
> On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote:
>> On 08/12/2016 11:39, Vinod Koul wrote:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>>>> Vinod Koul writes:
>>>>> On Tue, Dec 06, 2016 at 01:14:2
Vinod Koul <vinod.k...@intel.com> writes:
> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>> Vinod Koul <vinod.k...@intel.com> writes:
>>
>> > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>> >>
>>
Vinod Koul writes:
> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>> Vinod Koul writes:
>>
>> > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>> >>
>> >> That's not going to work very well. Device drivers typ
Vinod Koul <vinod.k...@intel.com> writes:
> On Wed, Dec 07, 2016 at 04:44:55PM +0000, Måns Rullgård wrote:
>> Vinod Koul <vinod.k...@intel.com> writes:
>> >>
>> >> What you're proposing, Vinod, is to make a channel exclusive
>> >> to a
Vinod Koul writes:
> On Wed, Dec 07, 2016 at 04:44:55PM +0000, Måns Rullgård wrote:
>> Vinod Koul writes:
>> >>
>> >> What you're proposing, Vinod, is to make a channel exclusive
>> >> to a driver, as long as the driver has not explicitly releas
Vinod Koul <vinod.k...@intel.com> writes:
> On Tue, Dec 06, 2016 at 01:14:20PM +0000, Måns Rullgård wrote:
>>
>> That's not going to work very well. Device drivers typically request
>> dma channels in their probe functions or when the device is opened.
>&
Vinod Koul writes:
> On Tue, Dec 06, 2016 at 01:14:20PM +0000, Måns Rullgård wrote:
>>
>> That's not going to work very well. Device drivers typically request
>> dma channels in their probe functions or when the device is opened.
>> This means that reserv
lease_channel(), right?
>
> Precisely, but yes the downside of that is concurrent access are
> limited, but am not sure if driver implements virtual channels and
> allows that..
My driver implements virtual channels. The problem is that the physical
dma channels signal completion slightly too soon, at least with
mem-to-device transfers. Apparently we need to keep the sbox routing
until the peripheral indicates that it has actually received all the
data.
--
Måns Rullgård
; Precisely, but yes the downside of that is concurrent access are
> limited, but am not sure if driver implements virtual channels and
> allows that..
My driver implements virtual channels. The problem is that the physical
dma channels signal completion slightly too soon, at least with
mem-to-device transfers. Apparently we need to keep the sbox routing
until the peripheral indicates that it has actually received all the
data.
--
Måns Rullgård
Mason <slash@free.fr> writes:
> On 06/12/2016 14:14, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> On 06/12/2016 06:12, Vinod Koul wrote:
>>>
>>>> On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
>>>>
>>>>
Mason writes:
> On 06/12/2016 14:14, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> On 06/12/2016 06:12, Vinod Koul wrote:
>>>
>>>> On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
>>>>
>>>>> Is there a way to write
to deliberately cripple the software
support in order to shoehorn it into an incomplete model of how hardware
ought to work. While I agree it would be nicer if all hardware actually
did work that way, this isn't the reality we're living in.
--
Måns Rullgård
the software
support in order to shoehorn it into an incomplete model of how hardware
ought to work. While I agree it would be nicer if all hardware actually
did work that way, this isn't the reality we're living in.
--
Måns Rullgård
Mason <slash@free.fr> writes:
> On 25/11/2016 16:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I've had several talks with the HW dev, and I don't think they
>>> anticipated the need to mux the 3 channels. In their minds,
>>>
Mason writes:
> On 25/11/2016 16:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I've had several talks with the HW dev, and I don't think they
>>> anticipated the need to mux the 3 channels. In their minds,
>>> customers would choose at most 3 d
Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 02:40:21PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
>>
>> > On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 02:40:21PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
>> >> Russell King - ARM Linux writes:
>> >
Mason <slash@free.fr> writes:
> On 25/11/2016 15:17, Russell King - ARM Linux wrote:
>> On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
>>> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
>>>
>>>> On Fri, No
Mason writes:
> On 25/11/2016 15:17, Russell King - ARM Linux wrote:
>> On Fri, Nov 25, 2016 at 02:03:20PM +0000, Måns Rullgård wrote:
>>> Russell King - ARM Linux writes:
>>>
>>>> On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
Mason <slash@free.fr> writes:
> On 25/11/2016 15:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 25/11/2016 12:57, Måns Rullgård wrote:
>>>
>>>> The same DMA unit is also used for SATA, which is an off the shelf
>>>&g
Mason writes:
> On 25/11/2016 15:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 25/11/2016 12:57, Måns Rullgård wrote:
>>>
>>>> The same DMA unit is also used for SATA, which is an off the shelf
>>>> Designware controller with
Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 02:03:20PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
>>
>> > On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 02:03:20PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
>> >> Russell King - ARM Linux writes:
>>
Mason <slash@free.fr> writes:
> On 25/11/2016 14:11, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> It seems there is a disconnect between what Linux expects - an IRQ
>>> when the transfer is complete - and the quirks of this HW :-(
>>>
&g
Mason writes:
> On 25/11/2016 14:11, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> It seems there is a disconnect between what Linux expects - an IRQ
>>> when the transfer is complete - and the quirks of this HW :-(
>>>
>>> On this syste
Mason <slash@free.fr> writes:
> On 25/11/2016 12:57, Måns Rullgård wrote:
>
>> The same DMA unit is also used for SATA, which is an off the shelf
>> Designware controller with an in-kernel driver. This interrupt timing
>> glitch can actually explain some int
Mason writes:
> On 25/11/2016 12:57, Måns Rullgård wrote:
>
>> The same DMA unit is also used for SATA, which is an off the shelf
>> Designware controller with an in-kernel driver. This interrupt timing
>> glitch can actually explain some intermittent errors I've obser
Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 01:50:35PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
>> > It would be unfair to augment the API and add the burden on everyone
&g
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 01:50:35PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>> > It would be unfair to augment the API and add the burden on everyone
>> > for the new API when 99.999% of the world doesn't requi
Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 01:07:05PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
>>
>> > On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
>&g
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 01:07:05PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
>> >> Looking at thread and discussion no
e
> when the controller has finished writing N bytes
>
> In that case, the IRQ does not indicate that the transfer
> is complete, merely that the sending half has finished
> its part.
When does your NAND controller signal completion? When it has received
the DMA data, or only when it has finished the actual write operation?
> I think it is possible to have a generic solution:
> Right now, the callback is called from tasklet context.
> If we can have a new flag to have the callback invoked
> directly from the ISR, then the driver for the client
> device can do what is required.
No, that won't work. The callback shouldn't run in interrupt context.
--
Måns Rullgård
shed writing N bytes
>
> In that case, the IRQ does not indicate that the transfer
> is complete, merely that the sending half has finished
> its part.
When does your NAND controller signal completion? When it has received
the DMA data, or only when it has finished the actual write operation?
> I think it is possible to have a generic solution:
> Right now, the callback is called from tasklet context.
> If we can have a new flag to have the callback invoked
> directly from the ISR, then the driver for the client
> device can do what is required.
No, that won't work. The callback shouldn't run in interrupt context.
--
Måns Rullgård
allback can do
the necessary waiting (e.g. by busy-polling a device status register).
If the delay can be longer, some other method needs to be devised.
--
Måns Rullgård
t.
The fix has to provide some way for the dma driver to delay reusing a
hardware channel until the client device indicates completion. If only
a short delay (a few bus cycles) is needed, it is probably acceptable to
rework the driver such that the descriptor completion callback can do
the necessary waiting (e.g. by busy-polling a device status register).
If the delay can be longer, some other method needs to be devised.
--
Måns Rullgård
errors I've observed with
it.
One possible solution is to add a new function for device drivers to
call when their end is complete. Existing DMA drivers would simply do
nothing, and device drivers could have this call added whenever the need
arises.
--
Måns Rullgård
it.
One possible solution is to add a new function for device drivers to
call when their end is complete. Existing DMA drivers would simply do
nothing, and device drivers could have this call added whenever the need
arises.
--
Måns Rullgård
Mason <slash@free.fr> writes:
> On 24/11/2016 15:17, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> [ 35.085854] SETUP DMA
>>> [ 35.088272] START NAND TRANSFER
>>> [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq
>&g
Mason writes:
> On 24/11/2016 15:17, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> [ 35.085854] SETUP DMA
>>> [ 35.088272] START NAND TRANSFER
>>> [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq
>>> [ 35.096882] tango_dma_cal
e a different flag DMA_PREP_INTERRUPT_EX can request
> calling the call-back directly from within the ISR?
>
> (Looking at existing flags) Could I use DMA_CTRL_ACK?
> Description sounds like some kind hand-shake between
> client and dmaengine.
>
> Grepping for DMA_PREP_INTERRUPT, I don't see where the framework
> checks that flag to spawn the tasklet? Or is that up to each
> driver individually?
Those flags all have defined meanings and abusing them for other things
is a bad idea. As far as possible, device drivers should work with any
dma driver.
--
Måns Rullgård
EP_INTERRUPT_EX can request
> calling the call-back directly from within the ISR?
>
> (Looking at existing flags) Could I use DMA_CTRL_ACK?
> Description sounds like some kind hand-shake between
> client and dmaengine.
>
> Grepping for DMA_PREP_INTERRUPT, I don't see where the framework
> checks that flag to spawn the tasklet? Or is that up to each
> driver individually?
Those flags all have defined meanings and abusing them for other things
is a bad idea. As far as possible, device drivers should work with any
dma driver.
--
Måns Rullgård
> Fixup tangox_dma_reset
> Relax write accesses
I have some other and conflicting fixes not in the github repo. You
should have asked me before sending this.
Since I'll end up supporting this, I'd really appreciate a little more
cooperation from your side.
--
Måns Rullgård
elax write accesses
I have some other and conflicting fixes not in the github repo. You
should have asked me before sending this.
Since I'll end up supporting this, I'd really appreciate a little more
cooperation from your side.
--
Måns Rullgård
Mason <slash@free.fr> writes:
> On 23/11/2016 13:13, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> On my platform, setting up a DMA transfer is a two-step process:
>>>
>>> 1) configure the "switch box" to connect a device to a
Mason writes:
> On 23/11/2016 13:13, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> On my platform, setting up a DMA transfer is a two-step process:
>>>
>>> 1) configure the "switch box" to connect a device to a memory channel
>&g
use after a dmaengine_terminate_async() call to wait for the
dma engine to finish whatever it was doing. This is not the problem
here. Your problem is that the dma engine interrupt fires before the
transfer is actually complete. Although you get an indication from the
target device when it has received all the data, there is no way to make
the dma driver wait for this.
--
Måns Rullgård
_async() call to wait for the
dma engine to finish whatever it was doing. This is not the problem
here. Your problem is that the dma engine interrupt fires before the
transfer is actually complete. Although you get an indication from the
target device when it has received all the data, there is no way to make
the dma driver wait for this.
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> Hi Måns,
>
> On 11/05/2016 01:58 PM, Måns Rullgård wrote:
>>> if (gigabit) {
>>> - if (priv->phy_mode == PHY_INTERFACE_MODE_RGMII)
>>> + if (phy_interface_is_rgmii(phydev))
&
Sebastian Frias writes:
> Hi Måns,
>
> On 11/05/2016 01:58 PM, Måns Rullgård wrote:
>>> if (gigabit) {
>>> - if (priv->phy_mode == PHY_INTERFACE_MODE_RGMII)
>>> + if (phy_interface_is_rgmii(phydev))
>>
pad_mode = PAD_MODE_RGMII;
> - break;
> -
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> pad_mode = PAD_MODE_RGMII;
> break;
> --
> 1.7.11.2
>
--
Måns Rullgård
; - break;
> -
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> pad_mode = PAD_MODE_RGMII;
> break;
> --
> 1.7.11.2
>
--
Måns Rullgård
gt; + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> pad_mode = PAD_MODE_RGMII;
> break;
> --
> 1.7.11.2
>
--
Måns Rullgård
GMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> pad_mode = PAD_MODE_RGMII;
> break;
> --
> 1.7.11.2
>
--
Måns Rullgård
Florian Fainelli <f.faine...@gmail.com> writes:
> On 11/04/2016 08:36 AM, Sebastian Frias wrote:
>> Hi Måns,
>>
>> On 11/04/2016 04:18 PM, Måns Rullgård wrote:
>>> Sebastian Frias <s...@laposte.net> writes:
>>>
>>>> The delay
Florian Fainelli writes:
> On 11/04/2016 08:36 AM, Sebastian Frias wrote:
>> Hi Måns,
>>
>> On 11/04/2016 04:18 PM, Måns Rullgård wrote:
>>> Sebastian Frias writes:
>>>
>>>> The delay can be applied at PHY or MAC level, but since
>>&g
pad_mode = PAD_MODE_RGMII;
>> break;
>
> How many boards use this Ethernet driver? How many boards are your
> potentially breaking, because they need this delay?
>
> I guess it is a small number, because doesn't it require the PHY is
> also broken, not adding a delay when it should?
What if the PHY doesn't have that option?
--
Måns Rullgård
break;
>
> How many boards use this Ethernet driver? How many boards are your
> potentially breaking, because they need this delay?
>
> I guess it is a small number, because doesn't it require the PHY is
> also broken, not adding a delay when it should?
What if the PHY doesn't have that option?
--
Måns Rullgård
s), that case
should be merged with the one above it and PHY_INTERFACE_MODE_RGMII_RXID
added as well.
--
Måns Rullgård
NTERFACE_MODE_RGMII_TXID:
> - pad_mode = PAD_MODE_RGMII | PAD_MODE_GTX_CLK_DELAY;
> + pad_mode = PAD_MODE_RGMII;
> break;
>
> default:
> --
> 1.7.11.2
If this change is correct (and I'm not convinced it is), that case
should be merged with the one above it and PHY_INTERFACE_MODE_RGMII_RXID
added as well.
--
Måns Rullgård
gt; index 453dc0967125..d5f2ad1a5a30 100644
> --- a/drivers/net/ethernet/aurora/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -1357,6 +1357,7 @@ static const struct of_device_id nb8800_dt_ids[] = {
> },
> { }
> };
> +MODULE_DEVICE_TABLE(of, nb8800_dt_ids);
>
> static int nb8800_probe(struct platform_device *pdev)
> {
> --
--
Måns Rullgård
ra/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -1357,6 +1357,7 @@ static const struct of_device_id nb8800_dt_ids[] = {
> },
> { }
> };
> +MODULE_DEVICE_TABLE(of, nb8800_dt_ids);
>
> static int nb8800_probe(struct platform_device *pdev)
> {
> --
--
Måns Rullgård
x buffer allocation failed\n");
> dev->stats.rx_dropped++;
> + dev_kfree_skb(skb);
> return;
> }
>
> --
> 2.7.4
>
--
Måns Rullgård
+ dev_kfree_skb(skb);
> return;
> }
>
> --
> 2.7.4
>
--
Måns Rullgård
800_ethtool_ops = {
> .get_sset_count = nb8800_get_sset_count,
> .get_strings= nb8800_get_strings,
> .get_ethtool_stats = nb8800_get_ethtool_stats,
> + .get_link_ksettings = phy_ethtool_get_link_ksettings,
> + .set_link_ksettings = phy_ethtool_set_link_ksettings,
> };
>
> static int nb8800_hw_init(struct net_device *dev)
> --
> 1.7.4.4
>
--
Måns Rullgård
truct phy_device *phydev = dev->phydev;
>
> priv->pause_aneg = pp->autoneg;
> priv->pause_rx = pp->rx_pause;
> @@ -1088,8 +1089,8 @@ static int nb8800_set_pauseparam(struct net_device *dev,
>
> if (!priv->pause_aneg)
> nb8800_p
.get_strings= nb8800_get_strings,
> .get_ethtool_stats = nb8800_get_ethtool_stats,
> + .get_link_ksettings = phy_ethtool_get_link_ksettings,
> + .set_link_ksettings = phy_ethtool_set_link_ksettings,
> };
>
> static int nb8800_hw_init(struct net_device *dev)
> --
> 1.7.4.4
>
--
Måns Rullgård
;pause_aneg = pp->autoneg;
> priv->pause_rx = pp->rx_pause;
> @@ -1088,8 +1089,8 @@ static int nb8800_set_pauseparam(struct net_device *dev,
>
> if (!priv->pause_aneg)
> nb8800_pause_config(dev);
> - else if (priv->phydev)
> - phy_start_aneg(priv->phydev);
> + else if (phydev)
> + phy_start_aneg(phydev);
>
> return 0;
> }
> diff --git a/drivers/net/ethernet/aurora/nb8800.h
> b/drivers/net/ethernet/aurora/nb8800.h
> index e5adbc2..6ec4a95 100644
> --- a/drivers/net/ethernet/aurora/nb8800.h
> +++ b/drivers/net/ethernet/aurora/nb8800.h
> @@ -284,7 +284,6 @@ struct nb8800_priv {
>
> struct mii_bus *mii_bus;
> struct device_node *phy_node;
> - struct phy_device *phydev;
>
> /* PHY connection type from DT */
> int phy_mode;
> --
> 1.7.4.4
>
--
Måns Rullgård
Arnd Bergmann <a...@arndb.de> writes:
> On Wednesday 11 May 2016 13:57:08 Måns Rullgård wrote:
>> > diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
>> > index 41b0725e58ad..8f7a4a4d2566 100644
>> > --- a/drivers/ata/Kconfig
>> > +++ b/driver
Arnd Bergmann writes:
> On Wednesday 11 May 2016 13:57:08 Måns Rullgård wrote:
>> > diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
>> > index 41b0725e58ad..8f7a4a4d2566 100644
>> > --- a/drivers/ata/Kconfig
>> > +++ b/drivers/ata/Kconfig
&
SATA_DWC
> + depends on SATA_DWC && DMADEVICES
> select DW_DMAC_CORE
> default y if 460EX
> help
> --
Isn't the proper fix here to have DW_DMAC_CORE select DMADEVICES?
--
Måns Rullgård
amp;& DMADEVICES
> select DW_DMAC_CORE
> default y if 460EX
> help
> --
Isn't the proper fix here to have DW_DMAC_CORE select DMADEVICES?
--
Måns Rullgård
/tj/libata.git/log/?h=for-4.7
>>
>> Oops, build failure. Reverted for now.
>
> I suppose you have to pull material from Vinod.
The failure the build bot reported is due to the DMA patches not being
in the tree.
--
Måns Rullgård
s, build failure. Reverted for now.
>
> I suppose you have to pull material from Vinod.
The failure the build bot reported is due to the DMA patches not being
in the tree.
--
Måns Rullgård
of "DMA transfer".) These sizes should be
selected properly to ensure error-free bus transfers. It is required
that the DMA write burst transfer does not cross the 8192-byte Data
FIS boundary, because the Transport Layer maintains the DMA state for
the duration of the Data FIS transmission.
--
Måns Rullgård
hese sizes should be
selected properly to ensure error-free bus transfers. It is required
that the DMA write burst transfer does not cross the 8192-byte Data
FIS boundary, because the Transport Layer maintains the DMA state for
the duration of the Data FIS transmission.
--
Måns Rullgård
only to
> force a hardware-reset when the PHY is wedged by some random event.
Yes, and some variants of this phy are broken and require a hard reset
in certain situations. At least that's what the comment in the code
says.
--
Måns Rullgård
hould behave in
>> at803x_link_change_notify without control of the reset line, because
>> this code isn't reached then.
>
> If I understand correctly, it is possible to soft-reset the PHY
> by writing to a specific register. The GPIO pin is useful only to
> force a hardware-res
ndy Shevchenko wrote:
>> >>
>> >> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <m...@mansr.com> wrote:
>> >>
>> >>> Not very surprising either. The number of people using Linux on avr32
>> >>> is probably approximately z
One Thousand Gnomes writes:
> On Wed, 9 Mar 2016 21:30:55 +0200
> Andy Shevchenko wrote:
>
>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck wrote:
>> > On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>> >>
>> >> On Sat, Feb 6, 2016 at 7:28 P
101 - 200 of 818 matches
Mail list logo
