Hi Geert,
On 31/05/18 05:55, Geert Uytterhoeven wrote:
On Wed, May 30, 2018 at 2:28 AM, Greg Ungerer wrote:
On 28/05/18 20:15, Geert Uytterhoeven wrote:
On Mon, May 28, 2018 at 7:26 AM, Finn Thain
wrote:
On Mon, 28 May 2018, Michael Schmitz wrote:
Am 27.05.2018 um 17:49 schrieb Finn
Hi Geert,
On 31/05/18 05:55, Geert Uytterhoeven wrote:
On Wed, May 30, 2018 at 2:28 AM, Greg Ungerer wrote:
On 28/05/18 20:15, Geert Uytterhoeven wrote:
On Mon, May 28, 2018 at 7:26 AM, Finn Thain
wrote:
On Mon, 28 May 2018, Michael Schmitz wrote:
Am 27.05.2018 um 17:49 schrieb Finn
Hi Greg,
On Wed, May 30, 2018 at 2:28 AM, Greg Ungerer wrote:
> On 28/05/18 20:15, Geert Uytterhoeven wrote:
>> On Mon, May 28, 2018 at 7:26 AM, Finn Thain
>> wrote:
>>> On Mon, 28 May 2018, Michael Schmitz wrote:
Am 27.05.2018 um 17:49 schrieb Finn Thain:
> On Sun, 27 May 2018,
Hi Greg,
On Wed, May 30, 2018 at 2:28 AM, Greg Ungerer wrote:
> On 28/05/18 20:15, Geert Uytterhoeven wrote:
>> On Mon, May 28, 2018 at 7:26 AM, Finn Thain
>> wrote:
>>> On Mon, 28 May 2018, Michael Schmitz wrote:
Am 27.05.2018 um 17:49 schrieb Finn Thain:
> On Sun, 27 May 2018,
Hi Geert,
On 28/05/18 20:15, Geert Uytterhoeven wrote:
On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote:
On Mon, 28 May 2018, Michael Schmitz wrote:
Am 27.05.2018 um 17:49 schrieb Finn Thain:
On Sun, 27 May 2018, Michael Schmitz wrote:
That should have fixed the warning already ...
Hi Geert,
On 28/05/18 20:15, Geert Uytterhoeven wrote:
On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote:
On Mon, 28 May 2018, Michael Schmitz wrote:
Am 27.05.2018 um 17:49 schrieb Finn Thain:
On Sun, 27 May 2018, Michael Schmitz wrote:
That should have fixed the warning already ...
Hi Finn,
On Tue, May 29, 2018 at 5:38 PM, Finn Thain wrote:
> I found some patches here,
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent.2
That's the most recent IIRC. Haven't begun looking at that yet - still stuck at
Hi Finn,
On Tue, May 29, 2018 at 5:38 PM, Finn Thain wrote:
> I found some patches here,
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent.2
That's the most recent IIRC. Haven't begun looking at that yet - still stuck at
On Mon, 28 May 2018, Geert Uytterhoeven wrote:
>
> Do we have a consensus on the way forward? The merge window for v4.18
> will open soon.
I'm content to let you and Christoph decide how best to deal with this.
Don't wait for me to find consensus ;-)
--
On Mon, 28 May 2018, Geert Uytterhoeven wrote:
>
> Do we have a consensus on the way forward? The merge window for v4.18
> will open soon.
I'm content to let you and Christoph decide how best to deal with this.
Don't wait for me to find consensus ;-)
--
On Tue, 29 May 2018, Christoph Hellwig wrote:
> Btw, can I get a review and testing for the above? They aren't really
> experimental any more, and I'd like to move architectures over as soon
> as possible.
When I boot the generic-dma-noncoherent.2 branch (5f4613b2dcd4) in qemu
and run
On Tue, 29 May 2018, Christoph Hellwig wrote:
> Btw, can I get a review and testing for the above? They aren't really
> experimental any more, and I'd like to move architectures over as soon
> as possible.
When I boot the generic-dma-noncoherent.2 branch (5f4613b2dcd4) in qemu
and run
On Tue, May 29, 2018 at 03:38:23PM +1000, Finn Thain wrote:
> On Tue, 29 May 2018, Michael Schmitz wrote:
>
> > >
> > > Since an arch gets to apply limits in the dma ops it implements, why
> > > would arch code also have to set a limit in the form of default
> > > platform device masks?
On Tue, May 29, 2018 at 03:38:23PM +1000, Finn Thain wrote:
> On Tue, 29 May 2018, Michael Schmitz wrote:
>
> > >
> > > Since an arch gets to apply limits in the dma ops it implements, why
> > > would arch code also have to set a limit in the form of default
> > > platform device masks?
On Tue, May 29, 2018 at 07:59:37AM +1200, Michael Schmitz wrote:
> Hi Geert,
>
> my preference would be Finn's patch introducing a m68k
> arch_setup_pdev_archdata(). It nicely preserves what bus code sets up
> prior to registering a platform device (important for Zorro devices
> using platform or
On Tue, May 29, 2018 at 07:59:37AM +1200, Michael Schmitz wrote:
> Hi Geert,
>
> my preference would be Finn's patch introducing a m68k
> arch_setup_pdev_archdata(). It nicely preserves what bus code sets up
> prior to registering a platform device (important for Zorro devices
> using platform or
On Tue, 29 May 2018, Michael Schmitz wrote:
> >
> > Since an arch gets to apply limits in the dma ops it implements, why
> > would arch code also have to set a limit in the form of default
> > platform device masks? Powerpc seems to be the only arch that does
> > this.
>
> One of Christoph's
On Tue, 29 May 2018, Michael Schmitz wrote:
> >
> > Since an arch gets to apply limits in the dma ops it implements, why
> > would arch code also have to set a limit in the form of default
> > platform device masks? Powerpc seems to be the only arch that does
> > this.
>
> One of Christoph's
Hi Finn,
Am 29.05.2018 um 14:15 schrieb Finn Thain:
>
> Since an arch gets to apply limits in the dma ops it implements, why would
> arch code also have to set a limit in the form of default platform device
> masks? Powerpc seems to be the only arch that does this.
One of Christoph's recent
Hi Finn,
Am 29.05.2018 um 14:15 schrieb Finn Thain:
>
> Since an arch gets to apply limits in the dma ops it implements, why would
> arch code also have to set a limit in the form of default platform device
> masks? Powerpc seems to be the only arch that does this.
One of Christoph's recent
On Mon, 28 May 2018, Geert Uytterhoeven wrote:
>
> Do we have a consensus on the way forward?
My prefered solution remains the two driver patches that I originally
submitted, which you objected to:
https://lkml.org/lkml/2018/5/3/10
https://lkml.org/lkml/2018/5/3/9
So there is no consensus
On Mon, 28 May 2018, Geert Uytterhoeven wrote:
>
> Do we have a consensus on the way forward?
My prefered solution remains the two driver patches that I originally
submitted, which you objected to:
https://lkml.org/lkml/2018/5/3/10
https://lkml.org/lkml/2018/5/3/9
So there is no consensus
Hi Geert,
my preference would be Finn's patch introducing a m68k
arch_setup_pdev_archdata(). It nicely preserves what bus code sets up
prior to registering a platform device (important for Zorro devices
using platform or mfd devices), and allows overriding by drivers that
need it.
If ever a
Hi Geert,
my preference would be Finn's patch introducing a m68k
arch_setup_pdev_archdata(). It nicely preserves what bus code sets up
prior to registering a platform device (important for Zorro devices
using platform or mfd devices), and allows overriding by drivers that
need it.
If ever a
On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote:
> On Mon, 28 May 2018, Michael Schmitz wrote:
>> Am 27.05.2018 um 17:49 schrieb Finn Thain:
>> > On Sun, 27 May 2018, Michael Schmitz wrote:
>> >
>> >> That should have fixed the warning already ...
>> >
>> > It's
On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote:
> On Mon, 28 May 2018, Michael Schmitz wrote:
>> Am 27.05.2018 um 17:49 schrieb Finn Thain:
>> > On Sun, 27 May 2018, Michael Schmitz wrote:
>> >
>> >> That should have fixed the warning already ...
>> >
>> > It's still not fixed (hence my
On Sat, May 26, 2018 at 09:15:05PM -0700, Guenter Roeck wrote:
> Good point. Maybe it would be better to limit the warning to SMP systems
> instead of (unnecessarily) fixing drivers all over the place ?
No. The coherent_dma_mask is the mask used for dma_alloc_coherent and
dma_alloc_attrs. It
On Sat, May 26, 2018 at 09:15:05PM -0700, Guenter Roeck wrote:
> Good point. Maybe it would be better to limit the warning to SMP systems
> instead of (unnecessarily) fixing drivers all over the place ?
No. The coherent_dma_mask is the mask used for dma_alloc_coherent and
dma_alloc_attrs. It
On Mon, 28 May 2018, Michael Schmitz wrote:
> Hi Finn,
>
> Am 27.05.2018 um 17:49 schrieb Finn Thain:
> > On Sun, 27 May 2018, Michael Schmitz wrote:
> >
> >> That should have fixed the warning already ...
> >
> > It's still not fixed (hence my "acked-by" for Geunter's patch).
> >
>
> Odd -
On Mon, 28 May 2018, Michael Schmitz wrote:
> Hi Finn,
>
> Am 27.05.2018 um 17:49 schrieb Finn Thain:
> > On Sun, 27 May 2018, Michael Schmitz wrote:
> >
> >> That should have fixed the warning already ...
> >
> > It's still not fixed (hence my "acked-by" for Geunter's patch).
> >
>
> Odd -
Hi Finn,
Am 27.05.2018 um 17:49 schrieb Finn Thain:
> On Sun, 27 May 2018, Michael Schmitz wrote:
>
>> That should have fixed the warning already ...
>
> It's still not fixed (hence my "acked-by" for Geunter's patch).
>
Odd - does link order still matter even though the
Hi Finn,
Am 27.05.2018 um 17:49 schrieb Finn Thain:
> On Sun, 27 May 2018, Michael Schmitz wrote:
>
>> That should have fixed the warning already ...
>
> It's still not fixed (hence my "acked-by" for Geunter's patch).
>
Odd - does link order still matter even though the
On Sun, 27 May 2018, Michael Schmitz wrote:
> That should have fixed the warning already ...
It's still not fixed (hence my "acked-by" for Geunter's patch).
--
On Sun, 27 May 2018, Michael Schmitz wrote:
> That should have fixed the warning already ...
It's still not fixed (hence my "acked-by" for Geunter's patch).
--
Hi Finn,
was your patch to implement this in arch_setup_pdev_archdata() rejected?
That should have fixed the warning already ...
Am 27.05.2018 um 15:01 schrieb Finn Thain:
> On Sat, 26 May 2018, Guenter Roeck wrote:
>
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>>
Hi Finn,
was your patch to implement this in arch_setup_pdev_archdata() rejected?
That should have fixed the warning already ...
Am 27.05.2018 um 15:01 schrieb Finn Thain:
> On Sat, 26 May 2018, Guenter Roeck wrote:
>
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>>
Hi,
On Sun, May 27, 2018 at 01:01:11PM +1000, Finn Thain wrote:
> On Sat, 26 May 2018, Guenter Roeck wrote:
>
> > As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> > coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
> > following warning on driver initialization
Hi,
On Sun, May 27, 2018 at 01:01:11PM +1000, Finn Thain wrote:
> On Sat, 26 May 2018, Guenter Roeck wrote:
>
> > As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> > coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
> > following warning on driver initialization
On Sat, 26 May 2018, Guenter Roeck wrote:
> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
> following warning on driver initialization on Macintosh q800 systems.
>
> SONIC ethernet @50f0a000, MAC
On Sat, 26 May 2018, Guenter Roeck wrote:
> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
> following warning on driver initialization on Macintosh q800 systems.
>
> SONIC ethernet @50f0a000, MAC
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
following warning on driver initialization on Macintosh q800 systems.
SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3
[ cut here ]
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
following warning on driver initialization on Macintosh q800 systems.
SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3
[ cut here ]
42 matches
Mail list logo