Re: [PATCH 15/21] sparc: add checks for the return value of memblock_alloc*()

[David Miller]

From: Mike Rapoport 
Date: Wed, 16 Jan 2019 15:44:15 +0200

> Add panic() calls if memblock_alloc*() returns NULL.
> 
> Most of the changes are simply addition of
> 
> if(!ptr)
> panic();
> 
> statements after the calls to memblock_alloc*() variants.
> 
> Exceptions are pcpu_populate_pte() and kernel_map_range() that were
> slightly refactored to accommodate the change.
> 
> Signed-off-by: Mike Rapoport 

Acked-by: David S. Miller 

Re: [PATCH net-next] Amiga PCMCIA 100 MBit card support

[David Miller]

From: Michael Schmitz 
Date: Sat, 22 Dec 2018 10:30:58 +1300

> Am 21.12.2018 um 13:10 schrieb David Miller:
>> And in particular this huge complicated Kconfig construct is not
>> maintainable at all.
> 
> We can trim this down a bit (for reasons I've outlined before):
> 
> +if APNE
> +config APNE100MBIT
> + bool "PCMCIA NE2000 100MBit support"
> + default n
> + depends on NE2000=n && PCMCIA_AXNET=n
> + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
> 
> In all honesty, I doubt anyone could ever use the stnic, ultra and wd
> drivers on m68k (Geert?) so these could be omitted as well. Not sure
> pcnet_cs or axnet_cs are possible to use on the Amiga PCMCIA slot, so
> all that remains in practice is the ne driver (which is used on
> Atari).
> 
> Still too ugly?

I'm sorry, maybe I didn't express my concern clearly.

Any sizable list of exceptions in a Kconfig conditional has long term
maintainence costs.  If, for some reason, a new variant of support
for this chip arrives there will be a new Kconfig setting that would
need to be added here to your expressions.

That is insanely error prone, and I can guarantee it will get missed.

Having so many front end drivers for a chipset should be done in a
more modular manner, so that in fact they could all coexist if
necessary.

Re: [PATCH net-next] Amiga PCMCIA 100 MBit card support

[David Miller]

From: ALeX Kazik 
Date: Wed, 19 Dec 2018 23:24:32 +0100

> + bool "PCMCIA NE2000 100MBit support"
> + default n
> + depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n
> + depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n
> + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
> + depends on XSURF100=n && ZORRO8390=n
> + ---help---

Generally I'm not too happy with these changes, they are all very hackish.

And in particular this huge complicated Kconfig construct is not
maintainable at all.

Sorry.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Jarkko Sakkinen 
Date: Fri, 30 Nov 2018 13:44:05 -0800

> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
>> No because use of what some people consider to be bad language isn't
>> necessarily abusive, offensive or degrading.  Our most heavily censored
>> medium is TV and "fuck" is now considered acceptable in certain
>> contexts on most channels in the UK and EU.
> 
> This makes following the CoC extremely hard to a non-native speaker as
> it is not too explicit on what is OK and what is not. I did through the
> whole thing with an eye glass and this what I deduced from it.

It would be helpful if you could explain what part of the language
is unclear wrt. explaining how CoC does not apply to existing code.

That part seems very explicit to me.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Jarkko Sakkinen 
Date: Fri, 30 Nov 2018 13:42:33 -0800

> Can you tell how the CoC should be interpreted then?

Regardless of what I think, as others have showen the CoC explicitly
does not apply to existing code.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Abuse 
Date: Fri, 30 Nov 2018 20:39:01 +

> I assume I will now be barred.

Perhaps, but not because you said fuck.  It would be because you're
intentionally creating a disturbance on the list and making it more
difficult for developers to get their work done and intentionally
creating a distraction and a hostile environment for the discussion at
hand.

That would not be censorship.

There is a big difference.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Jens Axboe 
Date: Fri, 30 Nov 2018 13:12:26 -0700

> On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
>> On Fri, 30 Nov 2018, Kees Cook wrote:
>> 
>>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>>>  wrote:

 In order to comply with the CoC, replace  with a hug.
>> 
>> I hope this is some kind of joke. How would anyone get offended by reading
>> technical comments? This is all beyond me...
> 
> Agree, this is insanity.

And even worse it is censorship.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Davidlohr Bueso 
Date: Fri, 30 Nov 2018 11:56:52 -0800

> I hope this is some kind of joke.

Whether or not it is a joke, it is censorship.

And because of that I have no intention to apply any patches like this
to any code I am in charge of.

Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions

[David Miller]

From: Joel Fernandes 
Date: Fri, 12 Oct 2018 05:50:46 -0700

> If its an issue, then how do transparent huge pages work on Sparc?  I don't
> see the huge page code (move_huge_pages) during mremap doing anything special
> for Sparc architecture when moving PMDs..

This is because all huge pages are larger than SHMLBA.  So no cache flushing
necessary.

> Also, do we not flush the caches from any path when we munmap
> address space?  We do call do_munmap on the old mapping from mremap
> after moving to the new one.

Sparc makes sure that shared mapping have consistent colors.  Therefore
all that's left are private mappings and those will be initialized by
block stores to clear the page out or similar.

Also, when creating new mappings, we flush the D-cache when necessary
in update_mmu_cache().

We also maintain a bit in the page struct to track when a page which
was potentially written to on one cpu ends up mapped into another
address space and flush as necessary.

The cache is write-through, which simplifies the preconditions we have
to maintain.

Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions

[David Miller]

From: "Kirill A. Shutemov" 
Date: Fri, 12 Oct 2018 14:30:56 +0300

> I looked into the code more and noticed move_pte() helper called from
> move_ptes(). It changes PTE entry to suite new address.
> 
> It is only defined in non-trivial way on Sparc. I don't know much about
> Sparc and it's hard for me to say if the optimization will break anything
> there.
> 
> I think it worth to disable the optimization if __HAVE_ARCH_MOVE_PTE is
> defined. Or make architectures state explicitely that the optimization is
> safe.

What sparc is doing in move_pte() is flushing the data-cache
(synchronously) if the virtual address color of the mapping changes.

Hope this helps.

Re: [PATCH 2/5] net: mac8390: Use standard memcpy_{from,to}io()

[David Miller]

From: Geert Uytterhoeven 
Date: Mon,  2 Jul 2018 15:35:29 +0200

> The mac8390 driver defines its own variants of memcpy_fromio() and
> memcpy_toio(), using similar implementations, but different function
> signatures.
> 
> Remove the custom definitions of memcpy_fromio() and memcpy_toio(), and
> adjust all callers to the standard signatures.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> This is a dependency for "m68k: Move mem*io define guards to
> ".
> 
> Untested on real hardware, assembler output compared.

Acked-by: David S. Miller 
--
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 v2 3/8] net: ax88796: Do not free IRQ in ax_remove() (already freed in ax_close()).

[David Miller]

From: Geert Uytterhoeven 
Date: Tue, 17 Apr 2018 10:20:25 +0200

> BTW, I have a git alias for that:
> 
> $ git help fixes
> `git fixes' is aliased to `show --format='Fixes: %h ("%s")' -s'
> $ git fixes 82533ad9a1c
> Fixes: 82533ad9a1c ("net: ethernet: ax88796: don't call free_irq
> without request_irq first")

Thanks for sharing :)
--
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 net 0/4] Fixes, cleanup and modernization for mac89x0 driver

[David Miller]

From: Finn Thain 
Date: Thu,  1 Mar 2018 18:29:28 -0500 (EST)

> Changes since v4 of combined patch series:
> - Removed redundant and non-portable MACH_IS_MAC tests.
> - Added acked-by tags from Geert Uytterhoeven.
> - Omitted patches unrelated to mac89x0 driver.

Series applied, thank you.
--
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 net 0/2] Fixes, cleanup and modernization for macmace driver

[David Miller]

From: Finn Thain 
Date: Tue, 27 Feb 2018 23:22:32 -0500 (EST)

> Changes since v4 of combined patch series:
> - Removed redundant and non-portable MACH_IS_MAC tests.
> - Omitted patches unrelated to macmace driver.

Series applied, thank you.
--
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 net 0/4] Fixes, cleanup and modernization for SONIC ethernet drivers

[David Miller]

From: Finn Thain 
Date: Sat, 24 Feb 2018 18:27:24 -0500 (EST)

> Changes since v4 of combined patch series:
> - Removed redundant and non-portable MACH_IS_MAC tests.
> - Omitted patches unrelated to SONIC drivers.
> - Dropped changes to the 'version_printed' logic and debug message text.

Series applied, thank you.
--
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] net/smc9194: Remove bogus CONFIG_MAC reference

[David Miller]

From: Finn Thain 
Date: Thu, 22 Feb 2018 09:24:59 +1100 (AEDT)

> AFAIK the only version of smc9194.c with Mac support is the one in the
> linux-mac68k CVS repo, which never made it to the mainline.
> 
> Despite that, from v2.3.45, arch/m68k/config.in listed CONFIG_SMC9194
> under CONFIG_MAC. This mistake got carried over into Kconfig in v2.5.55.
> (See pre-git era "[PATCH] add m68k dependencies to net driver config".)
> 
> Signed-off-by: Finn Thain 

Applied, thank you.
--
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 net 2/4] net/8390: Fix msg_enable patch snafu

[David Miller]

Ok I applied this series, thanks!
--
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 net 2/4] net/8390: Fix msg_enable patch snafu

[David Miller]

From: Finn Thain 
Date: Tue, 20 Feb 2018 11:42:26 +1100 (AEDT)

> If there was an unused variables I would happily remove that too but the 
> 'version' string is not unused. The etherh.c and mac8390.c files both 
> include "lib8390.c" and in there you'll find the 'version' string used in 
> ethdev_setup().

My bad, thanks for being so patient with me :)
--
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 net 2/4] net/8390: Fix msg_enable patch snafu

[David Miller]

From: Finn Thain <fth...@telegraphics.com.au>
Date: Tue, 20 Feb 2018 09:01:11 +1100 (AEDT)

> On Mon, 19 Feb 2018, David Miller wrote:
> 
>> From: Finn Thain <fth...@telegraphics.com.au>
>> Date: Sun, 18 Feb 2018 21:39:17 -0500 (EST)
>> 
>> > The lib8390 module parameter 'msg_enable' doesn't do anything useful:
>> > it causes an ancient version string to be logged.
>> 
>> Since you are removing the last reference to this 'version' string
>> you should remove it as well.
>> 
>> I'm surprised the compiler doesn't warn about this.
>> 
> 
> I compile-tested every 8390 module and I didn't come across any compiler 
> bugs.
> 
> Please take another look. I think you'll find that lib8390.c is always 
> #included by a module which does define that symbol.

But nothing references 'version' after you remove the log message.

You can therefore delete it.

And I'm politely asking you to.

Thank you.
--
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 net v4 02/13] net/8390: Fix msg_enable patch snafu

[David Miller]

From: Finn Thain <fth...@telegraphics.com.au>
Date: Thu, 15 Feb 2018 09:11:13 +1100 (AEDT)

> On Tue, 13 Feb 2018, David Miller wrote:
> 
>> > I think you have overlooked those modules which offer no way to set 
>> > p->msg_enable, i.e. ax88796, axnet_cs, etherh, hydra, mac8390, 
>> > mcf8390, pcnet_cs and zorro8390.
>> 
>> Then that's a bug, we have a very simple easy to implement interface for 
>> setting this (ethtool).
>> 
>> And by adding the simple hook, you will make these older drivers easier 
>> to debug for the few people still using them.
> 
> Have you considered that implementing the ethtool hooks in the core driver 
> might allow removal of all 8390 driver 'msg_enable' module parameters and 
> msglevel ethtool hooks added by c45f812f0280, excepting those in the core 
> driver? But even if we did that, it seems to me that we still need this 
> patch.

No, because the module parameter lets you set the default msg level at
the time the driver loads, so you can control messages printed very
early on before it is practical to invoke ethtool and set the msg
level.

This is why most drivers have this module parameter, and implement
such a scheme.
--
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 net v4 02/13] net/8390: Fix msg_enable patch snafu

[David Miller]

From: Finn Thain 
Date: Tue, 13 Feb 2018 16:03:09 +1100 (AEDT)

> I think you have overlooked those modules which offer no way to set 
> p->msg_enable, i.e. ax88796, axnet_cs, etherh, hydra, mac8390, mcf8390, 
> pcnet_cs and zorro8390.

Then that's a bug, we have a very simple easy to implement interface
for setting this (ethtool).

And by adding the simple hook, you will make these older drivers
easier to debug for the few people still using them.
--
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 net v4 02/13] net/8390: Fix msg_enable patch snafu

[David Miller]

From: Finn Thain 
Date: Sun, 11 Feb 2018 22:08:43 -0500 (EST)

> The lib8390 module parameter 'msg_enable' doesn't do anything useful:
> it causes an ancient version string to be logged.

Not true.

You need to look at the various netif_*() et al. message logging
interfaces, they check "p->msg_enable" to determine which messages to
print.

I'm not applying this, sorry.

Just for the record, I consider these kinds of ancient driver cleanups
painful to review, and unless they allow some ugly global kernel API
to be improved or removed such changes have very little gain.

In fact, most of them have a good chance to break things.

It is especially a dubious sequence when you cluster so many of these
things together into a large patch series.

If you are really serious about fixing real bugs, post these one at a
time, very slowly, for us to review properly and apply.

Thank you.
--
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 1/2] arch: Define CPU_BIG_ENDIAN for all fixed big endian archs

[David Miller]

From: Babu Moger 
Date: Thu,  8 Jun 2017 15:17:22 -0700

> While working on enabling queued rwlock on SPARC, found
> this following code in include/asm-generic/qrwlock.h
> which uses CONFIG_CPU_BIG_ENDIAN to clear a byte.
> 
> static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
>  {
>   return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
>  }
> 
> Problem is many of the fixed big endian architectures dont define
> CPU_BIG_ENDIAN and clears the wrong byte.
> 
> Define CPU_BIG_ENDIAN for all the fixed big endian architecture.
> 
> Here is the orinal discussion
> http://www.spinics.net/lists/devicetree/msg178101.html
> 
> Signed-off-by: Babu Moger 
> Suggested-by: Arnd Bergmann 

Acked-by: David S. Miller 
--
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 net-next] net: Remove usage of net_device last_rx member

[David Miller]

From: Tobias Klauser 
Date: Wed, 18 Jan 2017 17:45:01 +0100

> The network stack no longer uses the last_rx member of struct net_device
> since the bonding driver switched to use its own private last_rx in
> commit 9f242738376d ("bonding: use last_arp_rx in slave_last_rx()").
> 
> However, some drivers still (ab)use the field for their own purposes and
> some driver just update it without actually using it.
> 
> Previously, there was an accompanying comment for the last_rx member
> added in commit 4dc89133f49b ("net: add a comment on netdev->last_rx")
> which asked drivers not to update is, unless really needed. However,
> this commend was removed in commit f8ff080dacec ("bonding: remove
> useless updating of slave->dev->last_rx"), so some drivers added later
> on still did update last_rx.
> 
> Remove all usage of last_rx and switch three drivers (sky2, atp and
> smc91c92_cs) which actually read and write it to use their own private
> copy in netdev_priv.
> 
> Compile-tested with allyesconfig and allmodconfig on x86 and arm.
> 
> Cc: Eric Dumazet 
> Cc: Jay Vosburgh 
> Cc: Veaceslav Falico 
> Cc: Andy Gospodarek 
> Cc: Mirko Lindner 
> Cc: Stephen Hemminger 
> Signed-off-by: Tobias Klauser 

Applied, thanks.
--
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] phy: remove irq param to fix crash in fixed_phy_add()

[David Miller]

From: Florian Fainelli <f.faine...@gmail.com>
Date: Tue, 17 May 2016 11:27:12 -0700

> On 05/17/2016 11:20 AM, David Miller wrote:
>> From: Rabin Vincent <rabin.vinc...@axis.com>
>> Date: Mon, 16 May 2016 13:15:56 +0200
>> 
>>> From: Rabin Vincent <rab...@axis.com>
>>>
>>> Since e7f4dc3536a ("mdio: Move allocation of interrupts into core"),
>>> platforms which call fixed_phy_add() before fixed_mdio_bus_init() is
>>> called (for example, because the platform code and the fixed_phy driver
>>> use the same initcall level) crash in fixed_phy_add() since the
>>> ->mii_bus is not allocated.
>>>
>>> Also since e7f4dc3536a, these interrupts are initalized to polling by
>>> default.  All callers of both fixed_phy_register() and fixed_phy_add()
>>> pass PHY_POLL for the irq argument, so we can fix these crashes by
>>> simply removing the irq parameter, since the default is correct for all
>>> users.
>>>
>>> Fixes: e7f4dc3536a400 ("mdio: Move allocation of interrupts into core")
>>> Signed-off-by: Rabin Vincent <rab...@axis.com>
>> 
>> Applied.
> 
> David, there was a v2 sent just earlier this morning here:
> 
> http://patchwork.ozlabs.org/patch/622967/
> 
> which was appropriately marked with Changes Requested, so why would we
> apply v1?

And that v2 needs changes still.

My bad I'll revert v1, sorry.
--
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] phy: remove irq param to fix crash in fixed_phy_add()

[David Miller]

From: Rabin Vincent 
Date: Mon, 16 May 2016 13:15:56 +0200

> From: Rabin Vincent 
> 
> Since e7f4dc3536a ("mdio: Move allocation of interrupts into core"),
> platforms which call fixed_phy_add() before fixed_mdio_bus_init() is
> called (for example, because the platform code and the fixed_phy driver
> use the same initcall level) crash in fixed_phy_add() since the
> ->mii_bus is not allocated.
> 
> Also since e7f4dc3536a, these interrupts are initalized to polling by
> default.  All callers of both fixed_phy_register() and fixed_phy_add()
> pass PHY_POLL for the irq argument, so we can fix these crashes by
> simply removing the irq parameter, since the default is correct for all
> users.
> 
> Fixes: e7f4dc3536a400 ("mdio: Move allocation of interrupts into core")
> Signed-off-by: Rabin Vincent 

Applied.
--
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 0/5] net: m68k: Allow modular build

[David Miller]

From: Geert Uytterhoeven 
Date: Tue, 29 Sep 2015 10:24:01 +0200

> This patch series makes the remaining m68k Ethernet drivers modular.
> It's an alternative to the last 3 patches of Paul Gortmaker's series
> "[PATCH net-next 0/6] make non-modular code explicitly non-modular".
> 
> Note that "[PATCH 5/5] net: macmace: Allow modular build" depends on
> "[PATCH 4/5] m68k/mac: Export Peripheral System Controller (PSC) base
> address to modules". Feel free to take the dependency through the netdev
> tree to avoid modular build breakage.
> 
> This was compile-tested only (mac_defconfig + allmodconfig) due to lack
> of hardware.

Series applied, thanks Geert.
--
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] net: smc91x: Add Atari EtherNAT support

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Thu, 15 Jan 2015 14:06:15 +0100

 From: Michael Schmitz schmitz...@gmail.com
 
 Add Atari specific code to the smc91x Ethernet driver. This code is used
 on the EtherNAT adapter card for the Atari Falcon extension port.
 
 Signed-off-by: Michael Schmitz schm...@debian.org
 Tested-by: Christian Steigies c...@debian.org
 [geert: Sort Kconfig entries, split in hard and soft dependencies]
 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org

Applied to net-next, thanks.
--
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 0/2] trivial cleanup

[David Miller]

From: Amos Kong ak...@redhat.com
Date: Thu,  5 Jun 2014 11:01:20 +0800

 I found the RAM size in comments isn't correct,
 fix it.

Both patches applied, thank you.
--
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: esp_scsi QTAG in FAS216

[David Miller]

From: Michael Schmitz schmitz...@gmail.com
Date: Mon, 14 Apr 2014 10:38:09 +1200

 That appears to be our problem if I recall correctly Tuomas' debugging
 report. (reselection, not selection as initiator). As
 esp_slave_configure() enables queue tags regardless of chip config,
 we'd best make certain the chip is configured correctly.
 
 The SCSI2 bit is used to test for presence of config register 2 in
 esp_get_revision but later cleared in the same function. It appears
 we'd need to set it after the call to scsi_esp_register() - can you
 test whether that obsoletes the zorro_esp_slave_configure hack,
 Tuomas?
 ...
 Group 2 Commands
 (seems to only be relevant for target mode).

 And about the QTE bit:

 Bit 6 Queue Tag Enable

 When this bit is set, the 53CF94/96 can receive 3-byte messages during
 bus-initiated Select With ATN. This feature is also enabled by setting
 bit 3 in the Configuration 2 register.
 
 My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
 opinion, Dave?

As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode.  So it is not relevant for our discussion because this driver is
for initiator mode operation only.

But some pieces of documentation seem like they might not agree on
this point.

With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision.  As per ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.

But oddly in the NCR53CX docs:


http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt

it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.

Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.

Can we try testing the following patch?


esp_scsi: Set SCSI2 bit in config2 register.

This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.

Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net

diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
 */
esp-rev = ESP100;
} else {
-   esp-config2 = 0;
+   esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
-   esp-config2 = 0;
-   esp_write8(esp-config2, ESP_CFG2);
}
}
 }
--
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: esp_scsi QTAG in FAS216

[David Miller]

From: Michael Schmitz schmitz...@gmail.com
Date: Mon, 7 Apr 2014 08:33:12 +1200

 Hello Dave, Tuomas,
 
 Also, looking at the timeout formulae in the old NCR53C9x.c driver,
 the values would be different for FAS216. Why was this dropped from
 the modern esp_scsi?

 I've never seen a formula for any ESP or FAS chip for the timeout
 other than the one mentioned in huge comment in
 esp_set_clock_params(), although I do see the 7668 instead of 8192
 factor being used in the old NCR53C9x driver.
 
 I haven't gone far enough back in the 53C9x revision history to be
 certain. but it would seem to me that Kars de Jong added that FAS
 special case.
 
 Can you confirm that, Kars? Any recollection as to the reason?

Just as another reference point, I looked at the FreeBSD 'esp' driver
and it also uses the 8192 factor for all chips, including FAS216.
--
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: esp_scsi QTAG in FAS216

[David Miller]

From: Tuomas Vainikka tuomas.vaini...@aalto.fi
Date: Thu, 12 Sep 2013 18:36:09 +0300

 Does anyone have the register descriptions for the FAS216 chip? It
 would seem that receiving only one byte during reconnect is perfectly
 normal [1] unless SCSI-2 features are explicitly enabled (which
 esp_scsi doesn't seem to be doing).

This is quite possibly true.  I've never see it happen myself while
testing the driver though.

 Also, looking at the timeout formulae in the old NCR53C9x.c driver,
 the values would be different for FAS216. Why was this dropped from
 the modern esp_scsi?

I've never seen a formula for any ESP or FAS chip for the timeout
other than the one mentioned in huge comment in
esp_set_clock_params(), although I do see the 7668 instead of 8192
factor being used in the old NCR53C9x driver.

I wrote esp_scsi.c based upon the old sparc ESP driver and the docs
I had available to me.
--
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] m68k/atari - ide: do not register interrupt if host-get_lock is set

[David Miller]

From: Michael Schmitz schmitz...@gmail.com
Date: Thu, 6 Mar 2014 19:47:06 +1300

 Thanks Dave,
 
 On m68k, host-get_lock is used to both lock and register the
 interrupt
 that the IDE host shares with other device drivers. Registering the
 IDE interrupt handler in ide-probe.c results in duplicating the
 interrupt registered (once via host-get lock, and also via
 init_irq()),
 and may result in IDE accepting interrupts even when another driver
 has
 locked the interrupt hardware. This opens the whole locking scheme up
 to races.

 host-get_lock is set on m68k only, so other drivers' behaviour is not
 changed.

 Signed-off-by: Michael Schmitz schm...@debian.org

 It's a bit kludgy, but minimal and correct.
 
 Would you have preferred to use a host flag instead?

I looked into that, we are out of host flags.  We'd either need to expand
the flags value to 64-bits or add another u32.

That's overkill for this.
--
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] m68k/atari - ide: do not register interrupt if host-get_lock is set

[David Miller]

From: Michael Schmitz schmitz...@gmail.com
Date: Sat,  1 Feb 2014 13:48:13 +1300

 On m68k, host-get_lock is used to both lock and register the interrupt
 that the IDE host shares with other device drivers. Registering the
 IDE interrupt handler in ide-probe.c results in duplicating the
 interrupt registered (once via host-get lock, and also via init_irq()),
 and may result in IDE accepting interrupts even when another driver has
 locked the interrupt hardware. This opens the whole locking scheme up
 to races.
 
 host-get_lock is set on m68k only, so other drivers' behaviour is not
 changed.
 
 Signed-off-by: Michael Schmitz schm...@debian.org

It's a bit kludgy, but minimal and correct.

Applied, thank you.
--
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] net/7990: Make lance_private.name const

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Thu, 14 Nov 2013 09:37:32 +0100

 Sorry, I didn't get that message. I was puzzled by your request to correct
 the whitespace of the lines I touched only, which causes them to stand out
 in a block of old non-compliant whitespace.

It's very hard to stand out in this source file, even in the first
hunk of your patch the very next line already used proper TABs.
--
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] net/7990: Make lance_private.name const

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Wed, 13 Nov 2013 09:54:18 +0100

 On Wed, Nov 13, 2013 at 12:16 AM, David Miller da...@davemloft.net wrote:
 And remember about checkpatch.pl which was hardly content with the patch.

 Only because checkpatch looks at the _new_ lines, and doesn't compare the
 styles of the old and new lines.

 You really should fix the line you are changing to use tabs, please respin
 with this in mind, thanks.
 
 As that would add more to the TAB/space mess^H^H^Hix, I prepended a
 patch to fix all whitespace errors.

I implicitly asked you not to do this, now things are more difficult
and your original change will take longer to integrate.

Becuase now it isn't a patch set I can easily just apply quickly in
the current merge window, and it's therefore a series you'll have to
resubmit later when the merge window closes and the net-next tree
opens up again.

Sorry.
--
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] net/7990: Make lance_private.name const

[David Miller]

From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Date: Wed, 13 Nov 2013 01:04:17 +0300

 @@ -100,7 +100,7 @@ struct lance_init_block {
*/
   struct lance_private
   {
 -char *name;
 +const char *name;
 
Indent with tab, not spaces, please.

This whole file is %99 space indentation, you really can't blame
Geert for this.
--
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] net/7990: Make lance_private.name const

[David Miller]

From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Date: Wed, 13 Nov 2013 02:40:38 +0300

 On 11/13/2013 12:12 AM, David Miller wrote:
 
 @@ -100,7 +100,7 @@ struct lance_init_block {
 */
struct lance_private
{
 -char *name;
 +const char *name;
 
 Indent with tab, not spaces, please.
 
 This whole file is %99 space indentation, you really can't blame
 Geert for this.
 
It's never late to fix some. And remember about checkpatch.pl which
was hardly content with the patch.

Good point, Geert please respin this, thanks.
--
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] net/7990: Make lance_private.name const

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Tue, 12 Nov 2013 23:44:06 +0100

 On Wed, Nov 13, 2013 at 12:40 AM, Sergei Shtylyov
 sergei.shtyl...@cogentembedded.com wrote:
 On 11/13/2013 12:12 AM, David Miller wrote:

 @@ -100,7 +100,7 @@ struct lance_init_block {
 */
struct lance_private
{
 -char *name;
 +const char *name;


 Indent with tab, not spaces, please.


 This whole file is %99 space indentation, you really can't blame
 Geert for this.


It's never late to fix some.
 
 That would be a separate patch. Care to create and send it?
 
 And remember about checkpatch.pl which was hardly content with the patch.
 
 Only because checkpatch looks at the _new_ lines, and doesn't compare the
 styles of the old and new lines.

You really should fix the line you are changing to use tabs, please respin
with this in mind, thanks.
--
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] net/sun3_82586: Kill array subscript above array bounds warning

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Wed, 17 Jul 2013 14:25:05 +0200

 drivers/net/ethernet/i825xx/sun3_82586.c: In function 'sun3_82586_timeout':
 drivers/net/ethernet/i825xx/sun3_82586.c:993:89: warning: array subscript is 
 above array bounds [-Warray-bounds]
 
 Using the default NUM_XMIT_BUFFS = 1, there's only one transmit buffer.
 Hence accessing the second buffer is an out-of-bounds access.
 Print the command status of the first NOP buffer instead.
 
 Fortunately this actually worked fine, as the layout of transmit and NOP
 buffers is sufficiently similar.
 
 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org

Three more CPP directives in a DEBUG ifdef'd piece of code, yuck.

I'd say just kill this whole DEBUG section entirely.  If people
want this driver to print this debugging, do it properly with
netif_err() or similar.
--
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 v2 0/2] net: support for NS8390 based ethernet on ColdFire CPU boards

[David Miller]

From: g...@snapgear.com
Date: Thu, 5 Jul 2012 09:49:58 +1000

 
 This is version 2 of patches that add platform support for using the NS8390
 based ethernet ports used on some ColdFire CPU boards. This version
 incorporates only minor changes from the first.
 
 Patches to use these NS8390 devices on ColdFire boards have existed
 out-of-tree for years. Some of the base IO definitions (those in
 arch/m68k/include/asm/mcfne.h) have been in mainline, but unused for most
 of that time.
 
 The first patch just neatens up mcfne.h (moving it to mcf8390.h). The
 second patch is the platform driver. The first patch would normaly just
 go through the m68knommu git tree, but I figured keeping these together made
 more sense.

Applied, thanks.

Can you explain why we've had this completely unused header
file mcfne.h in the tree?  Was it used by some external driver
sources that were never merged?
--
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] irq: remove obsolete definitions in interrupt.h

[David Miller]

From: Sam Ravnborg s...@ravnborg.org
Date: Wed, 4 Apr 2012 09:45:54 +0200

 interrupt.h contained a small fixlet for the days when
 m68k and sparc32 did not use genirq.
 As they have both entered the modern world this
 fixlet can be dropped.
 
 Signed-off-by: Sam Ravnborg s...@ravnborg.org

Acked-by: David S. Miller da...@davemloft.net
--
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] m68k/atari: EtherNEC - rewrite to use mainstream ne.c, take two

[David Miller]

From: Michael Schmitz schmitz...@googlemail.com
Date: Sun, 01 Apr 2012 20:49:52 +1200

 Hi Paul, Geert,
 And on re-reading the comments in the other part of the patch, i.e.
 ...emulates the card interrupt via a timer  --perhaps the driver
 should be just fixed to support generic netpoll, instead of adding
 an arch specific thing that amounts to netpoll.  Then anyone can
 attempt to limp along and use one of these ancient relics w/o IRQ.
   
 Here's take two of my patch to convert the m68k Atari ROM port
 Ethernet driver to use mainstream ne.c, with minimal changes to the
 core NE2000 code.

Please fix your email client, it corrupts your outgoing patches
by breaking up long lines with newlines amongst other things.
--
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 09/11] net/ariadne: Improve debug prints

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Wed, 21 Mar 2012 10:51:53 +0100

 Remove casts and use proper printf()-style format specifiers instead.
 
 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org

You can merge these in via the m68k tree if you want.

Acked-by: David S. Miller da...@davemloft.net
--
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] net/ethernet: Move mac89x0.c from apple to cirrus

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Sat, 29 Oct 2011 20:09:01 +0200

 Macintosh CS89x0 based ethernet cards use a Crystal Semiconductor (Now
 Cirrus Logic) CS89x0 chip, so the mac89x0 driver should be in
 drivers/net/ethernet/cirrus instead of drivers/net/ethernet/apple.
 
 This also fixes a build problem, as the driver needs a header file from the
 cirrus directory:
 
 drivers/net/ethernet/apple/mac89x0.c:107:20: error: cs89x0.h: No such file or 
 directory
 
 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org

Applied, thanks.
--
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] macmace, macsonic: cleanup

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Wed, 14 Sep 2011 03:30:25 +1000 (EST)

 
 We check ether_type before registering the platform device in 
 arch/m68k/mac/config.c. Doing the same test again in the driver is 
 redundant so remove it.
 
 Multiple probes should not happen since the conversion to platform devices,
 so lose that test too.
 
 Then macmace.c need not include macintosh.h, so remove that and irq.h and 
 include linux/interrupt.h explicitly.
 
 Tested on PowerBook 520, Quadra 660av, LC 630.
 
 Signed-off-by: Finn Thain fth...@telegraphics.com.au

Applied to net-next, thanks.
--
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] mac_esp: remove redundant mutual exclusion

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Sun, 11 Sep 2011 01:01:34 +1000 (EST)

 Mutual exclusion is redundant here because all the paths in the call graph 
 leading to esp_driver_ops.send_dma_cmd() happen under spin_lock_irqsave/ 
 spin_lock_irqrestore. Remove it.
 
 Tested on a Mac Quadra 660av and a Mac LC 630.
 
 Signed-off-by: Finn Thain fth...@telegraphics.com.au

This patch should be CC:'d to linux-scsi not netdev

I understand how the networking maintainer is very responsive
and the SCSI maintainer generally takes forever, so your
Freudian slip will go unjudged :-)
--
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] macmace: disable only the dma interrupt

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Sun, 11 Sep 2011 01:02:16 +1000 (EST)

 Don't disable all interrupts, just disable the relevant one.
 
 Also move a couple of printk calls outside of local_irq_save/restore.
 
 Tested on a Quadra 660av.
 
 Signed-off-by: Finn Thain fth...@telegraphics.com.au

Using disable_irq() is very expensive, and when done from an interrupt
handler can deadlock especially on SMP (which I understand might not
be relevant here).

I really can't see why you'd do things this way, especially since
interrupt handlers under Linux now unconditionally always run with cpu
interrupts disabled.
--
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] net/hplance: hplance_init() should be __devinit

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Mon, 13 Jun 2011 20:17:36 +0200

 WARNING: vmlinux.o(.devinit.text+0x253e): Section mismatch in reference from 
 the function hplance_init_one() to the function .init.text:hplance_init()
 
 The forward declaration had the correct attribute, but the actual function
 definition hadn't.
 
 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org

Applied, thanks.
--
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 1/4] sparc: _sparc_find_resource() should check for exact matches

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Sat, 21 May 2011 21:39:13 +0200

 The address that's passed to _sparc_find_resource() should always be the
 start address of a resource:
   - iounmap() passes a page-aligned virtual address, while the original
 address was created by adding the in-page offset to the resource's
 start address,
   - sbus_free_coherent() and pci32_free_coherent() should be passed an
 address obtained from sbus_alloc_coherent() resp. pci32_alloc_coherent(),
 which is always a resource's start address.
 
 Hence replace the range check by a check for an exact match.
 
 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org

Acked-by: David S. Miller da...@davemloft.net
--
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 4/4] sparc: iounmap() and *_free_coherent() - Use lookup_resource()

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Sat, 21 May 2011 21:39:16 +0200

 Replace a custom implementation (which doesn't lock the resource tree) by a
 call to lookup_resource()
 
 Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org

Acked-by: David S. Miller da...@davemloft.net
--
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 1/3] module: deal with alignment issues in built-in module versions

[David Miller]

From: Linus Torvalds torva...@linux-foundation.org
Date: Thu, 17 Feb 2011 10:06:40 -0800

 David, why are you saying that regular just mark the structure
 alignment correctly doesn't work?

Because it's been proven to not work:

http://marc.info/?l=linux-kernelm=129674396021733w=2
http://marc.info/?l=linux-kernelm=129674399621795w=2
http://marc.info/?l=linux-kernelm=129674396121739w=2
http://marc.info/?l=linux-kernelm=129674396021735w=2

GCC is very clever with static objects these days.

It thinks that, because you mark something static, it can align it
any way it wants because it controls the domain in which the object
exists.  It knows that the object can't be part of an array, and
therefore no external entity can be concerned about the true size of
the object (specifically wrt. side effects of the alignment of the
object).

In these cases it takes the explicit alignment attribute as a minimum,
not as an absolute requirement.

But we lie to the compiler, we mark things static then put them into a
special a special section, then try to iterate over those objects
globally as an array and expect the compiler to lay them all out
with identical alignments and sizes everywhere.

And this doesn't work.
--
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 1/3] module: deal with alignment issues in built-in module versions

[David Miller]

From: Linus Torvalds torva...@linux-foundation.org
Date: Thu, 17 Feb 2011 13:11:56 -0800

 EVERY SINGLE OF YOUR ARGUMENTS WORK FOR pointer TOO!

It at least will not happen at the current time, because GCC only
plays these games on aggregates.

Also, for exception tables, we've avoided this problem because
we emit the exception tables by hand using inline asm and therefore
explicitly control all aspects of the alignment and size.

The GCC manual even documents the alignment attribute behavior.

Also, please don't shoot the messenger, I didn't make GCC behave this
way but I doubt you'll have any luck undoing this behavior in the
tools which therefore means as pragmatists we have to handle it one
way or another.
--
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 1/3] module: deal with alignment issues in built-in module versions

[David Miller]

From: Linus Torvalds torva...@linux-foundation.org
Date: Thu, 17 Feb 2011 13:54:57 -0800

 Is there a -fdata-align or something? Or would __attribute__((packed))
 help? Something that explicitly tells gcc don't do this, instead of
 let's add indirection and hope gcc doesn't add alignment for _that_.
 Especially as the extra pointer makes the code even uglier.

The tracing folks went down the path of trying to use packed in
various ways, to no avail, because no matter what they tried it broke
other things.

 And if we do have to use the pointer thing, let's at least then do the
 pointer with asms, so that gcc _really_ can't screw it up. Rather than
 just move the potential bug around.

That's fine with me.
--
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 1/3] module: deal with alignment issues in built-in module versions

[David Miller]

From: Dmitry Torokhov d...@vmware.com
Date: Thu, 17 Feb 2011 14:19:57 -0800

 Any pointers as to how to emit these pointers with asm?

.sectionFOO_SECTION, a
.align  SIZEOF_POINTER
.{,x}word   POINTER
.previous

Where FOO_SECTION is your special section name, SIZEOF_POINTER is
sizeof(void *), and POINTER is the pointer you want to add to the
section.

You have to also pick .word vs. .xword, or whatever the appropriate
sized pointer mnenomic is for a given architecture.  I know .word
works for 32-bit sparc, and .xword works for 64-bit sparc.
--
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: Early crash

[David Miller]

From: Dmitry Torokhov d...@vmware.com
Date: Mon, 7 Feb 2011 00:19:33 -0800

 So here is the patch that explicitly specifies alignment for struct
 module_version_attribute. I tested it on i386 and x86_64 and I believe
 it will fix the issue with m68k but I do not have access to such a box.

While this may or may not fix the m68k issue, this isn't really
sufficient to make this thing work in all cases.  And the older
tracepoint commits referenced in this thread are known to cause
problems with platforms such as sparc64.

You can't reliably put structures into independent objects, put them
into a special section, and then expect array access over them (via
the section boundaries) after linking the objects together to just
work.

Your attribute specification is only a lower-bound.

GCC can and does use variable alignment choices in different situations,
so the align directive in the various objects can all be different.  So
the array iteration will assume the iterations should use one object
size, but within the linked together section the alignments are all
different so the inter-struct gap is different.

The only portable mechanism that will work in all cases, as we've
found recently for tracepoints and similar, is to make an array of
plain pointers to the objects in the special section.

See:

http://marc.info/?l=linux-kernelm=129674396021733w=2
http://marc.info/?l=linux-kernelm=129674399621795w=2
http://marc.info/?l=linux-kernelm=129674396121739w=2
http://marc.info/?l=linux-kernelm=129674396021735w=2
--
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: Early crash

[David Miller]

From: Dmitry Torokhov d...@vmware.com
Date: Mon, 7 Feb 2011 08:58:29 -0800

 But, theoretically speaking, nothing stops GCC to align pointers with
 gaps as well? Let's say having everything (or some) aligned on
 quadword boundary even though arch is 32 bit?

The alignment business only applies to aggregates (ie. structs and
unions).

This has been confirmed via several weeks of expermentation with
different GCC versions on different platforms as well.
--
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: Early crash

[David Miller]

From: Rusty Russell ru...@rustcorp.com.au
Date: Tue, 8 Feb 2011 13:42:48 +1030

 But OTOH, this is an old problem which was faced by module params since
 pre-git.  And we use the-align-to-void*-size method there; I vaguely recall
 inserting it.
 
 You've now got me wondering whether these platforms have broken builtin
 module parameters, but I think it would crash iterating if you had any
 boot parameters at all if that were the case.
 
 So do we fix that now too, or wait for it to break?

Good question.

I think the magic align magic on x86_64 in gcc only kicks in if a
structure is larger than a certain size.  But of course they could
change that at some point if they like.

So probably better safe than sorry.
--
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 4/4] m68k/atari: ARAnyM - Add support for network access

[David Miller]

From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Sun,  6 Feb 2011 11:51:09 +0100

 + dev-trans_start = jiffies;

Device drivers no longer make this operation, the generic code
does it (see net/core/dev.c:dev_hard_start_xmit() and how it
invokes txq_trans_update() on -ndo_start_xmit() success).

Therefore, please remove this line.

 + pr_debug(DRV_NAME : send %d bytes\n, len);

For consistency with other network drivers, add an appropriate CPP
define for pr_fmt and use netdev_info(), netdev_debug(), etc.

In situations where a netdev pointer is not available
(ie. pre-register_netdev()), use dev_*() instead.

Thanks.
--
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 2/2] mac8390: raise error logging priority

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Tue, 1 Jun 2010 22:18:56 +1000 (EST)

 Log error conditions using KERN_ERR priority.
 
 Signed-off-by: Finn Thain fth...@telegraphics.com.au

Applied, thank you.
--
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] mac8390: change an error return code and some cleanup, take 4

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Sat, 29 May 2010 03:29:01 +1000 (EST)

 @@ -662,7 +665,7 @@ static void mac8390_no_reset(struct net_
  {
   ei_status.txing = 0;
   if (ei_debug  1)
 - pr_info(reset not supported\n);
 + printk(KERN_DEBUG pr_fmt(reset not supported\n));
   return;

Use pr_debug() or pr_devel().   Anything which explicitly codes
out a printk(KERN_* is suspect, we have interfaces for this. The
whole point of defining pr_fmt at the top of the driver is so
that in the driver, we use pr_foo() which includes the pr_fmt
string at the beginning.  If you bypass it you avoid the intended
effect of that pr_fmt define.

This is getting tiring Finn.

So we're already past 4 iterations of this silly simple patch, and I
want to remind you yet again what an incredibly hard time you gave Joe
Perches for his changes to this file which in the end were entirely
correct and well formed, and he got it right on his first attempt.

I advise you to think twice before snapping at another developer's
work in the future.

--
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] mac8390: change an error return code and some cleanup, take 4

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Mon, 31 May 2010 22:55:23 +1000 (EST)

 if (ei_debug)
   pr_debug(...)
 
 OR
 
 if (ei_debug)
   pr_info(...)

Well for the printk in question, it's telling the user that
a certain feature can't be enabled.

And if the driver has an explicit way to control this message,
using ei_debug, it's kind of redundant to slap another layer on
top by using the debug printk facility.

Changing this to a debug log level printk is only going to make
getting the debug message shown harder for the user.  So leaving it at
pr_info() is just as correct in my eyes.

Finally, your patch has so many problems getting applied because
you're doing multiple things in one patch.

And in fact I've asked you not to do this on several occiaions.

Fix the error return codes in one patch, and nothing more.
Then in another you can masterbate with printk log levels.
--
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] mac8390: change an error return code and some cleanup, take 4

[David Miller]

From: Joe Perches j...@perches.com
Date: Mon, 31 May 2010 08:08:13 -0700

 There are many uses of KERN_DEBUG that are reasonable to have
 always enabled.

Doubtful.

pr_debug() makes a ton of sense as currently implemented.
It's for messages that we want both compile time and
run-time control over.

The case we have here in mac8390 seems like it should stay
as pr_info().  Because 1) it's already controlled by a
run-time knob so controlling it even further is confusing
and 2) the message is informative, it lets the user know
a feature cannot be enabled, thus pr_info().
--
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] mac8390: change an error return code and some cleanup, take 3

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Sat, 17 Apr 2010 13:16:04 +1000 (EST)

 
 Change an error return code from -EAGAIN to -EBUSY since the former is 
 misleading.
 
 Nubus slots are geographically addressed and their irqs are equally 
 inflexible. -EAGAIN is misleading because retrying will not help fix 
 whatever bug it was that made the irq unavailable.

request_irq() itself returns an appropriate error code, so the
correct change is to do:

err = request_irq( ... );
if (err) {
...

and return 'err'.
--
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] mac8390: fix pr_info() calls and change return code

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Fri, 16 Apr 2010 23:57:34 +1000 (EST)

 
 On Thu, 15 Apr 2010, Joe Perches wrote:
 
 ...Why is it better to use -EBUSY?
 
 Nubus slots are geographically addressed and their irqs are equally 
 inflexible. -EAGAIN is misleading because retrying will not help fix 
 whatever bug caused the irq to unavailable.

This is exactly the kind of background information and verbose
explanation that belongs in the commit message.

Yet in your recent version of the patch, you're still being extremely
terse as per the reasoning for using -EBUSY

Just saying it's misleading doesn't tell anyone anything if they
have to go back in the commit history and try to figure out why this
change was made if it's causing problems later.

Please make the verbose and complete explanation in your commit
message, and resubmit your patch.

I just want to point out that with all the trouble you gave about
Joe's work, you're having one heck of a time even submitting your
changes properly. :-)

Thanks.
--
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] mac8390: fix pr_info() calls and change return code

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Fri, 16 Apr 2010 14:21:00 +1000 (EST)

  
 @@ -668,11 +668,11 @@
  {
   unsigned char *target = nubus_slot_addr(IRQ2SLOT(dev-irq));
   if (ei_debug  1)
 - pr_info(Need to reset the NS8390 t=%lu..., jiffies);
 + printk(KERN_DEBUG Need to reset the NS8390 t=%lu..., jiffies);
   ei_status.txing = 0;
   target[0xC] = 0;
   if (ei_debug  1)
 - pr_cont(reset complete\n);
 + printk(KERN_CONT reset complete\n);
   return;

You're missing the whole point of using pr_info() et al.  in that it
includes the bits we define for pr_fmt at the top of the file.

Also, you write absolutely no commit log message entry for your
change explaining why you're doing the things you are doing.

And finally you are doing two completely unrelated things at one
(changing error return values and changing log message levels).
--
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: sys_recvmmsg: wire up or not?

[David Miller]

From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 14 Jan 2010 15:20:33 +1100

 Anything happening here ? We're getting that warning on ppc too despite
 the fact that we use socketcall like x86... Should checksyscall be made
 smarter or the syscall just removed from x86 ? :-)

I think it's better to trap directly to the system call rather
than going through yet another demultiplexer.

I severely regretted using sys_socketcall initially on sparc32
because it added a few microseconds to socket syscall latency
(cpus back then were slow :-)
--
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] net: fix hydra printk format warning

[David Miller]

From: Randy Dunlap randy.dun...@oracle.com
Date: Fri, 4 Sep 2009 17:20:37 -0700

 From: Randy Dunlap randy.dun...@oracle.com
 
 m68k:
 drivers/net/hydra.c:178: warning: format '%08lx' expects type 'long unsigned 
 int', but argument 3 has type 'resource_size_t'
 
 Signed-off-by: Randy Dunlap randy.dun...@oracle.com

Applied to net-next-2.6, thanks.
--
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] mac8390: fix build with NET_POLL_CONTROLLER

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Thu, 28 May 2009 22:05:53 +1000 (EST)

 --- linux-2.6.29.orig/drivers/net/Makefile2009-05-28 15:15:13.0 
 +1000
 +++ linux-2.6.29/drivers/net/Makefile 2009-05-28 15:15:54.0 +1000
 @@ -489,7 +489,7 @@
   .ndo_set_mac_address= eth_mac_addr,
   .ndo_change_mtu = eth_change_mtu,
  #ifdef CONFIG_NET_POLL_CONTROLLER
 - .ndo_poll_controller= ei_poll,
 + .ndo_poll_controller= __ei_poll,
  #endif
  };

I don't think this is a patch to drivers/net/Makefile :-)

I've seen some patch screwups in my time, but this one
takes the cake as one of the most impressive ones :-)

I'll fix it up by hand, but realize that this makes more
work for me.
--
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] mac8390: use printk MAC address format

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Tue, 26 May 2009 12:52:47 +1000 (EST)

 
 mac8390: use printk MAC address format
 
 Signed-off-by: Finn Thain fth...@telegraphics.com.au

Applied to net-next-2.6, thanks.
--
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] mac8390: fix regression caused during net_device_ops conversion, take 2

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Thu, 28 May 2009 15:26:43 +1000 (EST)

 
 Changeset ca17584bf2ad1b1e37a5c0e4386728cc5fc9dabc broke mac8390 by adding 
 8390.o to the link. That meant that lib8390.c was included twice, once in 
 mac8390.c and once in 8390.c, subject to different macros. This patch 
 reverts that by avoiding the wrappers in 8390.c. They seem to be of no 
 value since COMPAT_NET_DEV_OPS is going away soon.
 
 Tested with a Kinetics EtherPort card.
 
 Signed-off-by: Finn Thain fth...@telegraphics.com.au

I already applied your other patch, it's in Linus's tree already
in fact.

So you need to send something relative to that.
--
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] mac8390: fix regression caused during net_device_ops conversion

[David Miller]

You need to post networking patches at least cc:'d to
net...@vger.kernel.org so that they get properly tracked
at:

http://patchwork.ozlabs.org/project/netdev/list/

otherwise your patches may (read as: will) get lost.

Thank you.
--
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] mac8390: fix regression caused during net_device_ops conversion

[David Miller]

From: Finn Thain fth...@telegraphics.com.au
Date: Tue, 26 May 2009 12:50:12 +1000 (EST)

 
 Changeset ca17584bf2ad1b1e37a5c0e4386728cc5fc9dabc broke mac8390 by adding 
 8390.o to the link. That meant that lib8390.c was included twice, once in 
 mac8390.c and once in 8390.c, subject to different macros. This patch 
 reverts that by avoiding the wrappers in 8390.c. They seem to be of no 
 value since COMPAT_NET_DEV_OPS is going away soon.
 
 Tested with a Kinetics EtherPort card.
 
 Signed-off-by: Finn Thain fth...@telegraphics.com.au

Patch applied, thanks.
--
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 1/6] ariadne: convert to net_device_ops

[David Miller]

From: Alexander Beregalov a.berega...@gmail.com
Date: Fri, 10 Apr 2009 07:24:07 +0400

 
 
 Signed-off-by: Alexander Beregalov a.berega...@gmail.com

Applied.
--
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 1/6] ariadne: convert to net_device_ops

[David Miller]

From: Alexander Beregalov a.berega...@gmail.com
Date: Fri, 10 Apr 2009 21:59:24 +0400

 On Fri, Apr 10, 2009 at 06:13:54PM +0200, Jan Ceuleers wrote:
 Alexander Beregalov wrote:
  
  Signed-off-by: Alexander Beregalov a.berega...@gmail.com
 ...
  @@ -197,13 +209,8 @@ static int __devinit ariadne_init_one(struct 
  zorro_dev *z,
   dev-mem_start = ZTWO_VADDR(mem_start);
   dev-mem_end = dev-mem_start+ARIADNE_RAM_SIZE;
   
  -dev-open = ariadne_open;
  -dev-stop = ariadne_close;
  -dev-hard_start_xmit = ariadne_start_xmit;
  -dev-tx_timeout = ariadne_tx_timeout;
  +dev-netdev_ops = ariadne_netdev_ops;;
 
 We don't really need two semicolons there but I suppose that they won't 
 hurt.
 Thanks!
 
 David, please apply this patch

Just FYI I made sure to integrate this fixed up version.
--
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 1/1] Remove of old NCR53C9x/esp family of drivers

[David Miller]

From: Finn Thain [EMAIL PROTECTED]
Date: Fri, 4 Jan 2008 22:05:20 +1100 (EST)

 I have a partially written replacement for mac_esp. Unlike the other 
 NCR53C9x drivers it needs PIO or pseudo DMA depending on the machine -- so 
 it is not as straight-forward as jazz_esp. The new esp_scsi core assumes 
 DMA and doesn't support asynch transfers. But I'll try to get it finished 
 before 2.6.25 is released.

It does actually support such things.

You can hide it completely your -irq_pending() handler.  Process any
pending pseudo DMA and return 0 until there is a pseudo DMA error or
the pseudo DMA is complete and the ESP is signalling an IRQ.
-
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers

[David Miller]

From: Geert Uytterhoeven [EMAIL PROTECTED]
Date: Thu, 3 Jan 2008 20:05:27 +0100 (CET)

 On Thu, 3 Jan 2008, James Bottomley wrote:
  On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote:
   As recommended by Christoph Hellwig. There is no use
of Fixing these drivers, since there is a much simpler
and modern esp infrastructure with David Miller's esp_scsi
   
 - Remove all driver files dependent on NCR53C9x.c
   deleted:drivers/scsi/NCR53C9x.c
   deleted:drivers/scsi/NCR53C9x.h
   deleted:drivers/scsi/blz1230.c
   deleted:drivers/scsi/blz2060.c
   deleted:drivers/scsi/cyberstorm.c
   deleted:drivers/scsi/cyberstormII.c
   deleted:drivers/scsi/dec_esp.c
   deleted:drivers/scsi/fastlane.c
   deleted:drivers/scsi/mac_esp.c
   deleted:drivers/scsi/mca_53c9x.c
   deleted:drivers/scsi/oktagon_esp.c
   deleted:drivers/scsi/oktagon_io.S
   deleted:drivers/scsi/sun3x_esp.c
   
 - Remove above list from drivers/scsi/Kconfig 
   drivers/scsi/Makefile
  
  OK, I'll split this into four pieces for scsi-pending, since there are
  three separate interest groups with signoffs to collect (MCA, m68k and
  alpha) plus the core removal.
 
 Anybody who can look into converting the m68k NCR53C9x drivers and has
 hardware to test (some of) them? I don't think we can afford losing one
 third of our SCSI drivers...

We can't wait forever, and effort spent maintaining the old
rotting drivers is effort that should instead be spent on
the converted new drivers.

Instead of seeing conversions being written, we've been hearing this
swan song from the m68k crowd forever, it's getting quite old.

I totally object to keeping these things around any longer.  And this
I support these changes going in.

Acked-by: David S. Miller [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cg3/bw2: add Sun3/Sun3x support

[David Miller]

From: Sam Creasey [EMAIL PROTECTED]
Date: Tue, 3 Apr 2007 10:32:35 -0400

 This patch (re) introduces support for the CG3 driver on Sun3, and for
 BW2 on Sun3x.  It applies cleanly to both the m68k CVS tree and the
 vanilla tree.
 
 Signed-off-by: Sam Creasey [EMAIL PROTECTED]

If you guys want to share driver code with the Sparc port, please do
it properly.

I am not applying a pile of ifdef's that basically duplicate half of
the existing driver.

What you can do instead is to build a fake openprom device tree and
register those devices with the generic device subsystem, and then the
driver will mostly just work out of the box.  It should be easy to
duplicate the arch/sparc64/kernel/prom.c and of_device.c code you
use as well as the driver interfaces in include/asm-sparc64/prom.h
and of_device.h

This way you don't need to shit all over the drivers adding hardcoded
register addresses and ad-hoc probing code.  For special behaviors,
you can add openprom node properties that the driver can test for at
run time to guide behavior, again instead of ifdefs.

Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cg3/bw2: add Sun3/Sun3x support

[David Miller]

From: Brad Boyer [EMAIL PROTECTED]
Date: Tue, 3 Apr 2007 13:18:25 -0700

 I don't know if the powerpc and sparc code are similar enough to
 have an exact shared version that would make everyone happy, but it
 might be worth investigating to save all of us some pain.

 A quick look at the sparc of_device.c reminds me a lot of the ppc
 version, but I don't know how deep the similarity goes without
 some time spent. Perhaps someone else knows the history?

The sparc code is based heavily on the ppc stuff, and Stephen
Rothwell, myself, and others are making as much match as possible
so we can put that bulk of the code into some common area.

Just copy what you need for now, and transitioning over later
on to the common bits will be very simple.
-
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html