Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region
Hi Geert, I haven't seen that weird behaviour in quite some time - we discussed changing the arch_initcall to some later priority at that time but I never got around to trying that. No change to mappings in head.S either as far as I could see. Was there any rearrangement of MM init relative to arch init since? Cheers, Michael On Tue, Apr 10, 2018 at 12:54 AM, Geert Uytterhoevenwrote: > Hi Finn, > > On Sun, Apr 1, 2018 at 3:41 AM, Finn Thain wrote: >> For reasons I don't understand, calling ioremap() then iounmap() on >> the SWIM MMIO region causes a hang on 68030 (but not on 68040). > > Michael Schmitz also notices strange things with ioremap() on '030. > >> There's no need to call ioremap() for the SWIM address range, as it lies >> within the usual IO device region at 0x5000 , which is already mapped. > > by head.S, right? > >> --- a/drivers/block/swim.c >> +++ b/drivers/block/swim.c >> @@ -911,7 +911,7 @@ static int swim_probe(struct platform_device *dev) >> goto out; >> } >> >> - swim_base = ioremap(res->start, resource_size(res)); >> + swim_base = (struct swim __iomem *)res->start; > > I guess you need a __force to please sparse? > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- > ge...@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like > that. > -- Linus Torvalds > -- > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region
Hi Geert, I haven't seen that weird behaviour in quite some time - we discussed changing the arch_initcall to some later priority at that time but I never got around to trying that. No change to mappings in head.S either as far as I could see. Was there any rearrangement of MM init relative to arch init since? Cheers, Michael On Tue, Apr 10, 2018 at 12:54 AM, Geert Uytterhoeven wrote: > Hi Finn, > > On Sun, Apr 1, 2018 at 3:41 AM, Finn Thain wrote: >> For reasons I don't understand, calling ioremap() then iounmap() on >> the SWIM MMIO region causes a hang on 68030 (but not on 68040). > > Michael Schmitz also notices strange things with ioremap() on '030. > >> There's no need to call ioremap() for the SWIM address range, as it lies >> within the usual IO device region at 0x5000 , which is already mapped. > > by head.S, right? > >> --- a/drivers/block/swim.c >> +++ b/drivers/block/swim.c >> @@ -911,7 +911,7 @@ static int swim_probe(struct platform_device *dev) >> goto out; >> } >> >> - swim_base = ioremap(res->start, resource_size(res)); >> + swim_base = (struct swim __iomem *)res->start; > > I guess you need a __force to please sparse? > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- > ge...@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like > that. > -- Linus Torvalds > -- > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region
On Mon, 9 Apr 2018, Geert Uytterhoeven wrote: > Hi Finn, > > On Sun, Apr 1, 2018 at 3:41 AM, Finn Thain> wrote: > > For reasons I don't understand, calling ioremap() then iounmap() on > > the SWIM MMIO region causes a hang on 68030 (but not on 68040). > > Michael Schmitz also notices strange things with ioremap() on '030. > > > There's no need to call ioremap() for the SWIM address range, as it > > lies within the usual IO device region at 0x5000 , which is > > already mapped. > > by head.S, right? > Right. I'll mention that in the commit log when I re-submit this series. > > --- a/drivers/block/swim.c > > +++ b/drivers/block/swim.c > > @@ -911,7 +911,7 @@ static int swim_probe(struct platform_device *dev) > > goto out; > > } > > > > - swim_base = ioremap(res->start, resource_size(res)); > > + swim_base = (struct swim __iomem *)res->start; > > I guess you need a __force to please sparse? > No, sparse did not find any new issues. It appears there's an old issue elsewhere in the driver though. I'll prepare a new patch for that. -- > Gr{oetje,eeting}s, > > Geert > > --
Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region
On Mon, 9 Apr 2018, Geert Uytterhoeven wrote: > Hi Finn, > > On Sun, Apr 1, 2018 at 3:41 AM, Finn Thain > wrote: > > For reasons I don't understand, calling ioremap() then iounmap() on > > the SWIM MMIO region causes a hang on 68030 (but not on 68040). > > Michael Schmitz also notices strange things with ioremap() on '030. > > > There's no need to call ioremap() for the SWIM address range, as it > > lies within the usual IO device region at 0x5000 , which is > > already mapped. > > by head.S, right? > Right. I'll mention that in the commit log when I re-submit this series. > > --- a/drivers/block/swim.c > > +++ b/drivers/block/swim.c > > @@ -911,7 +911,7 @@ static int swim_probe(struct platform_device *dev) > > goto out; > > } > > > > - swim_base = ioremap(res->start, resource_size(res)); > > + swim_base = (struct swim __iomem *)res->start; > > I guess you need a __force to please sparse? > No, sparse did not find any new issues. It appears there's an old issue elsewhere in the driver though. I'll prepare a new patch for that. -- > Gr{oetje,eeting}s, > > Geert > > --
Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region
On Mon, Apr 09, 2018 at 02:54:30PM +0200, Geert Uytterhoeven wrote: > > > > - swim_base = ioremap(res->start, resource_size(res)); > > + swim_base = (struct swim __iomem *)res->start; > > I guess you need a __force to please sparse? Hi, Only pointer-to-pointer conversions may need __force. The logic being if you use an integer type to hold an address this address is typeless anyway and has no address-space, so extra checking is not done in this case and the cast in itself is enough. Cheers, -- Luc
Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region
On Mon, Apr 09, 2018 at 02:54:30PM +0200, Geert Uytterhoeven wrote: > > > > - swim_base = ioremap(res->start, resource_size(res)); > > + swim_base = (struct swim __iomem *)res->start; > > I guess you need a __force to please sparse? Hi, Only pointer-to-pointer conversions may need __force. The logic being if you use an integer type to hold an address this address is typeless anyway and has no address-space, so extra checking is not done in this case and the cast in itself is enough. Cheers, -- Luc
Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region
Hi Finn, On Sun, Apr 1, 2018 at 3:41 AM, Finn Thainwrote: > For reasons I don't understand, calling ioremap() then iounmap() on > the SWIM MMIO region causes a hang on 68030 (but not on 68040). Michael Schmitz also notices strange things with ioremap() on '030. > There's no need to call ioremap() for the SWIM address range, as it lies > within the usual IO device region at 0x5000 , which is already mapped. by head.S, right? > --- a/drivers/block/swim.c > +++ b/drivers/block/swim.c > @@ -911,7 +911,7 @@ static int swim_probe(struct platform_device *dev) > goto out; > } > > - swim_base = ioremap(res->start, resource_size(res)); > + swim_base = (struct swim __iomem *)res->start; I guess you need a __force to please sparse? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Re: [PATCH 03/12] m68k/mac: Don't remap SWIM MMIO region
Hi Finn, On Sun, Apr 1, 2018 at 3:41 AM, Finn Thain wrote: > For reasons I don't understand, calling ioremap() then iounmap() on > the SWIM MMIO region causes a hang on 68030 (but not on 68040). Michael Schmitz also notices strange things with ioremap() on '030. > There's no need to call ioremap() for the SWIM address range, as it lies > within the usual IO device region at 0x5000 , which is already mapped. by head.S, right? > --- a/drivers/block/swim.c > +++ b/drivers/block/swim.c > @@ -911,7 +911,7 @@ static int swim_probe(struct platform_device *dev) > goto out; > } > > - swim_base = ioremap(res->start, resource_size(res)); > + swim_base = (struct swim __iomem *)res->start; I guess you need a __force to please sparse? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds