Hi Finn,
Am 11.05.2018 um 22:06 schrieb Finn Thain:
>> You would have to be careful not to overwrite a pdev->dev.dma_mask and
>> pdev->dev.dma_coherent_mask that might have been set in a platform
>> device passed via platform_device_register here. Coldfire is the only
>> m68k platform currently
On Fri, 11 May 2018, Michael Schmitz wrote:
>
> I wasn't proposing to follow platform_device_register() with the mask
> assignment,
I see.
> but rather to use the same strategy from the Coldfire FEC patch
> (f61e64310b75): set pdev.dev.coherent_dma_mask and pdev.dev.dma_mask
> _before_ calli
Hi Finn,
Am 11.05.2018 um 17:28 schrieb Finn Thain:
> On Fri, 11 May 2018, Michael Schmitz wrote:
>
>>
>> I'm afraid using platform_device_register() (which you already use for
>> the SCC devices) is the only option handling this on a per-device basis
>> without touching platform core code, whi
On Fri, 11 May 2018, Michael Schmitz wrote:
>
> I'm afraid using platform_device_register() (which you already use for
> the SCC devices) is the only option handling this on a per-device basis
> without touching platform core code, while at the same time keeping the
> DMA mask setup out of dev
Hi Finn,
Am 11.05.2018 um 15:28 schrieb Finn Thain:
> On Fri, 11 May 2018, Michael Schmitz wrote:
>
Which begs the question: why can' you set up all Nubus bus devices'
DMA masks in nubus_device_register(), or nubus_add_board()?
>>>
>>> I am expecting to see the same WARNING from the nu
On Fri, 11 May 2018, Michael Schmitz wrote:
> > > Which begs the question: why can' you set up all Nubus bus devices'
> > > DMA masks in nubus_device_register(), or nubus_add_board()?
> >
> > I am expecting to see the same WARNING from the nubus sonic driver but
> > it hasn't happened yet, so I
Hi Finn,
On Fri, May 11, 2018 at 11:55 AM, Finn Thain wrote:
>> > What's worse, if you do pass a dma_mask in struct
>> > platform_device_info, you end up with this problem in
>> > platform_device_register_full():
>> >
>> > if (pdevinfo->dma_mask) {
>> > /*
>> >
On Fri, 11 May 2018, Michael Schmitz wrote:
> > > Perhaps you can add a new helper
> > > (platform_device_register_simple_dma()?) that takes the DMA mask,
> > > too?
...
> >
> > So far, it looks like macmace and macsonic would be the only callers
> > of this new API call.
> >
> > What's worse,
Hi Finn,
On Thu, May 10, 2018 at 1:25 PM, Finn Thain wrote:
> On Thu, 3 May 2018, Geert Uytterhoeven wrote:
>
>>
>> Perhaps you can add a new helper
>> (platform_device_register_simple_dma()?) that takes the DMA mask, too?
[...]
> To actually hoist the dma mask setup out of existing platform driv
On Thu, 3 May 2018, Geert Uytterhoeven wrote:
>
> Perhaps you can add a new helper
> (platform_device_register_simple_dma()?) that takes the DMA mask, too?
Would there be enough potential callers in future to justify that API?
It seems that there haven't been many in the past. I found four user
On Thu, 3 May 2018, Christoph Hellwig wrote:
> On Thu, May 03, 2018 at 10:46:56AM +0200, Geert Uytterhoeven wrote:
> > Perhaps you can add a new helper
> > (platform_device_register_simple_dma()?) that takes the DMA mask, too?
> > With people setting the mask to kill the WARNING splat, this may
Hi Geert,
Am 04.05.2018 um 19:24 schrieb Geert Uytterhoeven:
> Hi Michael,
>
>>> Yes, that would be useful. The other assumption could be that
>>> platform devices always allow an all-0xff dma mask.
>>
>> That's not always true (Atari NCR5380 SCSI and floppy would use a 24
>> bit DMA mask). We u
Hi Michael,
On Thu, May 3, 2018 at 10:24 PM, Michael Schmitz wrote:
> On Thu, May 3, 2018 at 8:51 PM, Christoph Hellwig wrote:
>> On Thu, May 03, 2018 at 10:46:56AM +0200, Geert Uytterhoeven wrote:
>>> Perhaps you can add a new helper (platform_device_register_simple_dma()?)
>>> that takes the D
Hi Christoph,
On Thu, May 3, 2018 at 8:51 PM, Christoph Hellwig wrote:
> On Thu, May 03, 2018 at 10:46:56AM +0200, Geert Uytterhoeven wrote:
>> Perhaps you can add a new helper (platform_device_register_simple_dma()?)
>> that takes the DMA mask, too?
>> With people setting the mask to kill the WA
On Thu, May 03, 2018 at 10:46:56AM +0200, Geert Uytterhoeven wrote:
> Perhaps you can add a new helper (platform_device_register_simple_dma()?)
> that takes the DMA mask, too?
> With people setting the mask to kill the WARNING splat, this may become
> more common.
>
> struct platform_device_info a
Hi Finn,
CC Christoph
On Thu, May 3, 2018 at 10:38 AM, Finn Thain wrote:
> On Thu, 3 May 2018, Geert Uytterhoeven wrote:
>> > --- a/drivers/net/ethernet/apple/macmace.c
>> > +++ b/drivers/net/ethernet/apple/macmace.c
>> > @@ -203,6 +203,10 @@ static int mace_probe(struct platform_device *pdev)
>
On Thu, 3 May 2018, Geert Uytterhoeven wrote:
> > --- a/drivers/net/ethernet/apple/macmace.c
> > +++ b/drivers/net/ethernet/apple/macmace.c
> > @@ -203,6 +203,10 @@ static int mace_probe(struct platform_device *pdev)
> > unsigned char checksum = 0;
> > int err;
> >
> > + err
Hi Finn,
On Thu, May 3, 2018 at 6:23 AM, Finn Thain wrote:
> Set the device's coherent_dma_mask to avoid a WARNING splat.
> Please see commit 205e1b7f51e4 ("dma-mapping: warn when there is
> no coherent_dma_mask").
>
> Cc: linux-m...@lists.linux-m68k.org
> Tested-by: Stan Johnson
> Signed-off-by
Set the device's coherent_dma_mask to avoid a WARNING splat.
Please see commit 205e1b7f51e4 ("dma-mapping: warn when there is
no coherent_dma_mask").
Cc: linux-m...@lists.linux-m68k.org
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/net/ethernet/apple/macmace.c | 4
1 file c
19 matches
Mail list logo