b/arch/arm/mach-tango/smc.S
> @@ -1,6 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> #include
>
> + .arch_extension sec
> ENTRY(tango_smc)
> push{lr}
> mov ip, r1
For Tango:
Acked-by: Mans Rullgard
--
Måns Rullgård
an option for multiple reasons:
- We have two rootfs partitions for ping-pong updates, so simply
referring to "the thing with ID foo" doesn't work.
- Installing said updates needs direct access the device/partition,
which may not even have a filesystem.
- The u-boot environment is stored in an eMMC "boot" partition, and
userspace needs to know where to find it.
I'm sure I'm not the only one in a similar situation.
Russel, feel free to shout abuse at me. I don't care, but it makes you
look stupid.
--
Måns Rullgård
you mind if I change
> it before sending it to linux-next? Otherwise, looks fine to me.
> Thanks!
Of course I don't mind.
--
Måns Rullgård
g this marking).
The option is there so 'make oldconfig' on existing configurations
doesn't silently drop that driver since it now depends on AUXDISPLAY.
There have been similar cases when shuffling options. Maybe they used a
different tag. We could of course let the three people using that
driver deal with it themselves.
>> + depends on PARPORT
>> + select AUXDISPLAY
>> + select PARPORT_PANEL
>
> I agree the menu was a bit convoluted and we didn't get to clean it.
>
> Since you are touching the panel.c options, CC'ing the maintainers
> (please do run get_maintainer.pl in that case!)
I always run get_maintainer.pl on patches. Sometimes it isn't clever
enough to figure out all the people who might be interested.
--
Måns Rullgård
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
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
l(), 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
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 reserving on
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 r
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 driver
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:20PM
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 +, Mån
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
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 w
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 com
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 par
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:
>> >>
>> >> >
ired 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
_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
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
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
> maybe 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
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
restart.notifier_call = tangox_wdt_restart;
>> -dev->restart.priority = 128;
>> -err = register_restart_handler(&dev->restart);
>> -if (err)
>> -dev_warn(&pdev->dev, "failed to register restart handler\n");
>> -
>> dev_info(&pdev->dev, "SMP86xx/SMP87xx watchdog registered\n");
>>
>> return 0;
>> @@ -202,7 +193,6 @@ static int tangox_wdt_remove(struct platform_device
>> *pdev)
>> tangox_wdt_stop(&dev->wdt);
>> clk_disable_unprepare(dev->clk);
>>
>> -unregister_restart_handler(&dev->restart);
>> watchdog_unregister_device(&dev->wdt);
>>
>> return 0;
>>
--
Måns Rullgård
+ dev_kfree_skb(skb);
> return;
> }
>
> --
> 2.7.4
>
--
Måns Rullgård
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
ing we can do about that.
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
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
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 now, first t
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
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
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
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 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
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:
>>&g
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 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 a
David Laight writes:
> From: Måns Rullgård
>> Sent: 10 December 2016 13:25
> ...
>> I solved this problem in an Ethernet driver by copying the initial part
>> of the packet to an aligned skb and appending the remainder using
>> skb_add_rx_frag(). The kernel netw
k at the code I'm trying
to debug without wanting to claw my eyes out. In such cases, an initial
cleanup patch often makes the actual fix much easier to comprehend.
There's not a lot such code in the kernel, thankfully, but it does
exist.
> Said that, I call for a tree wide morat
Joe Perches writes:
> On Wed, 2016-12-14 at 18:13 +0000, Måns Rullgård wrote:
>> Alexey Dobriyan writes:
>> > I call for a tree wide moratorium on pure coding style changes.
> []
>> I'd relax this slightly and say don't do style
>> patches unless as a
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
>>>> vir
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
e 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
Felix Fietkau writes:
> On 2016-12-10 14:25, Måns Rullgård wrote:
>> Felix Fietkau writes:
>>
>>> On 2016-12-07 19:54, Jason A. Donenfeld wrote:
>>>> On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
>>>>> It's so much better to anal
ur protocol.
Always include some way of extending the protocol in the future. A
single bit is often enough. Require a value of zero initially, then if
you ever want to change anything, setting it to one can indicate
whatever you want, including a complete redesign of the header.
Alternatively, a o
Tomas Winkler writes:
> On Mon, Mar 6, 2017 at 2:31 AM, Måns Rullgård wrote:
>> Henrique de Moraes Holschuh writes:
>>
>>> On Sun, 05 Mar 2017, Måns Rullgård wrote:
>>>> Tomas Winkler writes:
>>>> > Sparse complains for arrays declared wi
Tomas Winkler writes:
> On Thu, Mar 9, 2017 at 3:02 PM, Måns Rullgård wrote:
>> Tomas Winkler writes:
>>
>>> On Mon, Mar 6, 2017 at 2:31 AM, Måns Rullgård wrote:
>>>> Henrique de Moraes Holschuh writes:
>>>>
>>>>> On Sun,
Tomas Winkler writes:
> On Thu, Mar 9, 2017 at 4:16 PM, Måns Rullgård wrote:
>> Tomas Winkler writes:
>>
>>> On Thu, Mar 9, 2017 at 3:02 PM, Måns Rullgård wrote:
>>>> Tomas Winkler writes:
>>>>
>>>>> On Mon, Mar 6, 2017 at 2:
Tomas Winkler writes:
> On Thu, Mar 9, 2017 at 4:26 PM, Måns Rullgård wrote:
>> Tomas Winkler writes:
>>
>>> On Thu, Mar 9, 2017 at 4:16 PM, Måns Rullgård wrote:
>>>> Tomas Winkler writes:
>>>>
>>>>> On Thu, Mar 9, 2017
ster for the frame pointer, and
it often prevents inlining.
--
Måns Rullgård
Henrique de Moraes Holschuh writes:
> On Sun, 05 Mar 2017, Måns Rullgård wrote:
>> Tomas Winkler writes:
>> > Sparse complains for arrays declared with variable length
>> >
>> > 'warning: Variable length array is used'
>> >
>> &g
.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
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
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
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
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
;
> - 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
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))
>>
k C permits for "undefined behavior, strictly speaking".
> Besides, that same mechanism is already used elsewhere, which is how I
> got the idea. Are you claiming that there are situations where it won't
> work ?
A pointer to void is interchangeable with any other pointer type. That
doesn't necessarily imply that pointers to functions taking arguments of
different pointer types (as we have here) are always compatible. I'd
have to read the C standard carefully to see if there's any such
promise, and I have other things to do right now. I am, however, not
aware of any ABI (certainly none used by Linux) where it would pose a
problem.
--
Måns Rullgård
ard stops just short of declaring pointer
to void compatible with other pointer types.
> However, I agree that it will work as expected on typical platforms
> (where all pointers are the same size, and the calling convention
> treats all pointers the same).
Yes, I don't see how it could possibly go wrong.
--
Måns Rullgård
ed object is typically not warned
about since the purpose of the call might be to initialise it in the
first place. Now the second argument of sigaction() is a pointer to
const, so the compiler should be able to see that this isn't the case.
Maybe it's not warning because some fields in the struct are initialised
and the function, as far as the compiler knows, might only be accessing
those. (There's certainly code out there using that pattern.) If this
is the case here, a flag to warn unless the object is fully initialised
would be useful to catch bugs like this.
--
Måns Rullgård
an be very hard to debug.
>
> One of the problems I've experienced is that Linux does support liberal
> memory ordering, even as extreme as the Alpha.
We don't really have much choice given the reality of existing hardware.
--
Måns Rullgård
Ralf Baechle writes:
> On Tue, Feb 02, 2016 at 02:54:06PM +0000, Måns Rullgård wrote:
>
>> We don't really have much choice given the reality of existing hardware.
>
> No, of course not - but I want us discourage new weakly ordered
> platforms as much as possible.
1571,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
>
> as->use_cs_gpios = true;
> if (atmel_spi_is_v2(as) &&
> + pdev->dev.of_node &&
> !of_get_property(pdev->dev.of_node, "cs-gpios", NULL)) {
> as->use_cs_gpios = false;
> master->num_chipselect = 4;
> --
> 2.1.3
>
--
Måns Rullgård
Julian Margetson writes:
> On 12/18/2015 8:49 AM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>>>> [5.206125] Unable to handle kernel paging request for data at
>>>>> address 0x
>>>>> [5.228546] Faulting inst
Julian Margetson writes:
> On 12/18/2015 1:18 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/18/2015 8:49 AM, Måns Rullgård wrote:
>>>> Andy Shevchenko writes:
>>>>
>>>>>>> [5.206125] Unable t
Julian Margetson writes:
> On 12/18/2015 6:33 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/18/2015 1:18 PM, Måns Rullgård wrote:
>>>> Julian Margetson writes:
>>>>
>>>>> On 12/18/20
Julian Margetson writes:
> On 12/18/2015 10:34 PM, Andy Shevchenko wrote:
>> On Sat, Dec 19, 2015 at 1:16 AM, Måns Rullgård wrote:
>>> Julian Margetson writes:
>>>
>>>> On 12/18/2015 6:33 PM, Måns Rullgård wrote:
>>>>> Julian Margetson wri
Julian Margetson writes:
> On 12/19/2015 11:40 AM, Måns Rullgård wrote:
>> OK, I've found something. The dma setup errors are benign, caused by
>> the driver calling dmaengine_prep_slave_sg() even for non-dma
>> operations. The real error is the lock recursion th
Andy Shevchenko writes:
> On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
>
>> OK, I've found something. The dma setup errors are benign, caused by
>> the driver calling dmaengine_prep_slave_sg() even for non-dma
>> operations.
>
> I suppose th
Julian Margetson writes:
> On 12/19/2015 1:05 PM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
>>>
>>>> OK, I've found something. The dma setup errors are benign, caused by
>
Julian Margetson writes:
> On 12/19/2015 1:19 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/19/2015 1:05 PM, Måns Rullgård wrote:
>>>> Andy Shevchenko writes:
>>>>
>>>>> On Sat, Dec 19, 2015 at 5:40 PM, Måns R
Andy Shevchenko writes:
> On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote:
>> On 12/19/2015 3:07 PM, Måns Rullgård wrote:
>>> Julian Margetson writes:
>
>>>> Total pages: 522752
>>>> [0.00] Kernel command line: root=/de
Julian Margetson writes:
> On 12/19/2015 4:41 PM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote:
>>>> On 12/19/2015 3:07 PM, Måns Rullgård wrote:
>>>>> Julian Margetson writ
Andy Shevchenko writes:
> On Sun, Dec 20, 2015 at 7:11 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/19/2015 4:41 PM, Måns Rullgård wrote:
>>>> Andy Shevchenko writes:
>>>>
>>>>> On Sat, Dec 19, 2015 at 10:16 P
Julian Margetson writes:
> On 12/20/2015 1:11 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/19/2015 4:41 PM, Måns Rullgård wrote:
>>>> Andy Shevchenko writes:
>>>>
>>>>> On Sat, Dec 19, 2015 at 10:16 PM, Jul
Andy Shevchenko writes:
> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote:
>>>> Julian Margetson writes:
>
>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUE
Måns Rullgård writes:
> Andy Shevchenko writes:
>
>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote:
>>> Julian Margetson writes:
>>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote:
>>>>> Julian Margetson writes:
>>
>>
Andy Shevchenko writes:
> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote:
>>>> Julian Margetson writes:
>
>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUE
Andy Shevchenko writes:
> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
> wrote:
>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote:
>>> Julian Margetson writes:
>>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote:
>>>>> Julian Margetson
Andy Shevchenko writes:
> +Viresh
>
> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote:
>>>> Julian Margetson writes:
>>>>> On 12/20/2015 1:11
Julian Margetson writes:
> On 12/21/2015 4:40 AM, Andy Shevchenko wrote:
>> +Viresh
>>
>> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård wrote:
>>> Andy Shevchenko writes:
>>>
>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote:
>&g
defined but not used [-Wunused-variable]
> static struct dw_dma_slave sata_dwc_dma_dws = {
> ^
> drivers/ata/sata_dwc_460ex.c:1279:13: warning:
> ‘sata_dwc_dma_filter’ defined but not used [-Wunused-function]
> static bool sata_dwc_dma_filter(struct dma
Julian Margetson writes:
> On 12/21/2015 9:24 AM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>>>>> P.S. Anyway we have to ask Julian to try the kernel with
>>>>>> 8b3444852a2b58129 reverted.
>>>>>>
>
Andy Shevchenko writes:
> On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> +Viresh
>>>
>>> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård wrote:
>>>> Andy Shevchenko writes:
>>>>
>>
Andy Shevchenko writes:
> On Mon, 2015-12-21 at 15:24 +0000, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>
>> Oh, that one again. My patch still applies. Here it is as applied
>> to
>> that revision of the file.
>>
>> From what I
ndy Shevchenko
>>>> wrote:
>>>>>
>>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård
>>>>> wrote:
>>>>> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
>>>>> items on this board, however reg
t;> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
>>>>> wrote:
>>>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård
>>>>>> wrote:
>>>>>> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32
>>>>&g
Andy Shevchenko writes:
> On Mon, 2015-12-21 at 01:19 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > P.S. I also noticed that original driver enables interrupt per each
>> > block
>>
>> And then ignores all but the transfer com
Julian Margetson writes:
> On 12/21/2015 2:27 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/21/2015 1:55 PM, Andy Shevchenko wrote:
>>>> On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson wrote:
>>>>> On 12/21/2015 12:48 P
Andy Shevchenko writes:
> On Mon, 2015-12-21 at 18:16 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård
>> > wrote:
>> > > Andy Shevchenko writes:
>> > >
>> > I used
Andy Shevchenko writes:
> On Mon, 2015-12-21 at 15:19 -0400, Julian Margetson wrote:
>> On 12/21/2015 2:27 PM, Måns Rullgård wrote:
>> > The hard drive is recognized .
>> > > These system gets unresponsive with USB devices like the mouse
>> > > and
&g
AVR32 (MMC, dmatest), PPC 460EX (Onboard
>> > SATA)
>>
>> I can test on AVR32. That is as far as I know the only system I have
>> with this DMA engine.
>
> If you have Intel Haswell, BayTrail, Braswell, CherryTrail, Broadwell,
> you have it as well as long yo
Andy Shevchenko writes:
> On Mon, 2015-12-21 at 19:27 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > I can share my working branch with a set of patches regarding to
>> > dw_dmac. We may do our work based on that code and after I'll
>>
I supposed
to know who the maintainers are if they're not listed in MAINTAINERS?
--
Måns Rullgård
ev->dev, "no PHY specified\n");
> + ret = -ENODEV;
> + goto err_free_bus;
> + }
> }
>
> priv->mii_bus = bus;
> --
> 2.1.4
>
--
Måns Rullgård
Mark Brown writes:
> On Fri, Feb 05, 2016 at 01:23:20PM +0000, Måns Rullgård wrote:
>> Mark Brown writes:
>
>> > Please remember to CC the maintainers for the driver when sending
>> > patches.
>
>> I CCd everybody scripts/get_maintainers.pl suggested
"phy-handle", 0);
if (!priv->phy_node) {
dev_err(&pdev->dev, "no PHY specified\n");
ret = -ENODEV;
goto err_free_bus;
}
--
Måns Rullgård
Sebastian Frias writes:
> On 02/05/2016 02:58 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> Signed-off-by: Sebastian Frias
>>> ---
>>> drivers/net/ethernet/aurora/nb8800.c | 15 ---
>>> 1 file changed, 12 inserti
301 - 400 of 433 matches
Mail list logo
