<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/arch/m68k/mac/misc.c, branch linux-rolling-stable</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-05-30T07:44:34Z</updated>
<entry>
<title>m68k: mac: Fix reboot hang on Mac IIci</title>
<updated>2024-05-30T07:44:34Z</updated>
<author>
<name>Finn Thain</name>
<email>fthain@linux-m68k.org</email>
</author>
<published>2024-05-04T04:31:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bde63834702c8f9ebd35094cd9d016da61a0084e'/>
<id>urn:sha1:bde63834702c8f9ebd35094cd9d016da61a0084e</id>
<content type='text'>
[ Upstream commit 265a3b322df9a973ff1fc63da70af456ab6ae1d6 ]

Calling mac_reset() on a Mac IIci does reset the system, but what
follows is a POST failure that requires a manual reset to resolve.
Avoid that by using the 68030 asm implementation instead of the C
implementation.

Apparently the SE/30 has a similar problem as it has used the asm
implementation since before git. This patch extends that solution to
other systems with a similar ROM.

After this patch, the only systems still using the C implementation are
68040 systems where adb_type is either MAC_ADB_IOP or MAC_ADB_II. This
implies a 1 MiB Quadra ROM.

This now includes the Quadra 900/950, which previously fell through to
the "should never get here" catch-all.

Reported-and-tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thain &lt;fthain@linux-m68k.org&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Link: https://lore.kernel.org/r/480ebd1249d229c6dc1f3f1c6d599b8505483fd8.1714797072.git.fthain@linux-m68k.org
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>m68k: mac: Add and use "mac.h"</title>
<updated>2023-10-06T08:03:03Z</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2023-09-13T14:08:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c43278f073c920a18af9721fb620c05f6826ff13'/>
<id>urn:sha1:c43278f073c920a18af9721fb620c05f6826ff13</id>
<content type='text'>
When building with W=1:

    arch/m68k/mac/iop.c:235:13: warning: no previous prototype for ‘iop_init’ [-Wmissing-prototypes]
      235 | void __init iop_init(void)
	  |             ^~~~~~~~
    arch/m68k/mac/via.c:112:13: warning: no previous prototype for ‘via_init’ [-Wmissing-prototypes]
      111 | void __init via_init(void)
	  |             ^~~~~~~~
    arch/m68k/mac/via.c:623:13: warning: no previous prototype for ‘via_init_clock’ [-Wmissing-prototypes]
      593 | void __init via_init_clock(void)
	  |             ^~~~~~~~~~~~~~
    arch/m68k/mac/oss.c:37:13: warning: no previous prototype for ‘oss_init’ [-Wmissing-prototypes]
       37 | void __init oss_init(void)
	  |             ^~~~~~~~
    arch/m68k/mac/psc.c:76:13: warning: no previous prototype for ‘psc_init’ [-Wmissing-prototypes]
       76 | void __init psc_init(void)
	  |             ^~~~~~~~
    arch/m68k/mac/baboon.c:25:13: warning: no previous prototype for ‘baboon_init’ [-Wmissing-prototypes]
       25 | void __init baboon_init(void)
	  |             ^~~~~~~~~~~
    arch/m68k/mac/macboing.c:155:6: warning: no previous prototype for ‘mac_mksound’ [-Wmissing-prototypes]
      155 | void mac_mksound( unsigned int freq, unsigned int length )
	  |      ^~~~~~~~~~~
    arch/m68k/mac/misc.c:608:5: warning: no previous prototype for ‘mac_hwclk’ [-Wmissing-prototypes]
      608 | int mac_hwclk(int op, struct rtc_time *t)
	  |     ^~~~~~~~~

Fix this by introducing a new header file "mac.h" for holding the
prototypes of functions implemented in arch/m68k/mac/.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Link: https://lore.kernel.org/r/d1fe0014a9e472a305333de4fa17f335c93d73af.1694613528.git.geert@linux-m68k.org
</content>
</entry>
<entry>
<title>m68k: mac: Remove unused yday in unmktime()</title>
<updated>2023-10-06T08:03:03Z</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2023-09-13T14:08:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4dae1950b494e5d75aaadc882a9276055d769887'/>
<id>urn:sha1:4dae1950b494e5d75aaadc882a9276055d769887</id>
<content type='text'>
When building with W=1:

    arch/m68k/mac/misc.c: In function ‘unmktime’:
    arch/m68k/mac/misc.c:557:33: warning: variable ‘yday’ set but not used [-Wunused-but-set-variable]
      557 |         int days, rem, y, wday, yday;
	  |                                 ^~~~

Fix this by removing the unused variable and assignment.

Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Link: https://lore.kernel.org/r/b25c42eac8beb0862f1b2041e817cb421ec66b4e.1694613528.git.geert@linux-m68k.org
</content>
</entry>
<entry>
<title>m68k: mac: Reword comment using double "in"</title>
<updated>2022-11-01T11:17:56Z</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2022-10-28T08:30:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=550a998f37b4f9c243501f735aa283c79189ba9b'/>
<id>urn:sha1:550a998f37b4f9c243501f735aa283c79189ba9b</id>
<content type='text'>
People keep on sending (incorrect) patches to remove the second
occurrence of the word "in".  Reword the comment to stop the inflood.

Suggested-by: Michael Schmitz &lt;schmitzmic@gmail.com&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Reviewed-by: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Link: https://lore.kernel.org/r/0229879ee3e2d8828707d291cddbb89ac18a10c2.1666945731.git.geert@linux-m68k.org
</content>
</entry>
<entry>
<title>m68k: Remove set_fs()</title>
<updated>2021-09-24T11:35:07Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2021-09-16T07:04:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9fde0348640252c79d462c4d29a09a14e8741f5c'/>
<id>urn:sha1:9fde0348640252c79d462c4d29a09a14e8741f5c</id>
<content type='text'>
Add a m68k-only set_fc helper to set the SFC and DFC registers for the
few places that need to override it for special MM operations, but
disconnect that from the deprecated kernel-wide set_fs() API.

Note that the SFC/DFC registers are context switched, so there is no need
to disable preemption.

Partially based on an earlier patch from
Linus Torvalds &lt;torvalds@linux-foundation.org&gt;.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Michael Schmitz &lt;schmitzmic@gmail.com&gt;
Tested-by: Michael Schmitz &lt;schmitzmic@gmail.com&gt;
Link: https://lore.kernel.org/r/20210916070405.52750-7-hch@lst.de
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'char-misc-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc</title>
<updated>2019-03-06T22:18:59Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-03-06T22:18:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=45763bf4bc1ebdf8eb95697607e1fd042a3e1221'/>
<id>urn:sha1:45763bf4bc1ebdf8eb95697607e1fd042a3e1221</id>
<content type='text'>
Pull char/misc driver updates from Greg KH:
 "Here is the big char/misc driver patch pull request for 5.1-rc1.

  The largest thing by far is the new habanalabs driver for their AI
  accelerator chip. For now it is in the drivers/misc directory but will
  probably move to a new directory soon along with other drivers of this
  type.

  Other than that, just the usual set of individual driver updates and
  fixes. There's an "odd" merge in here from the DRM tree that they
  asked me to do as the MEI driver is starting to interact with the i915
  driver, and it needed some coordination. All of those patches have
  been properly acked by the relevant subsystem maintainers.

  All of these have been in linux-next with no reported issues, most for
  quite some time"

* tag 'char-misc-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (219 commits)
  habanalabs: adjust Kconfig to fix build errors
  habanalabs: use %px instead of %p in error print
  habanalabs: use do_div for 64-bit divisions
  intel_th: gth: Fix an off-by-one in output unassigning
  habanalabs: fix little-endian&lt;-&gt;cpu conversion warnings
  habanalabs: use NULL to initialize array of pointers
  habanalabs: fix little-endian&lt;-&gt;cpu conversion warnings
  habanalabs: soft-reset device if context-switch fails
  habanalabs: print pointer using %p
  habanalabs: fix memory leak with CBs with unaligned size
  habanalabs: return correct error code on MMU mapping failure
  habanalabs: add comments in uapi/misc/habanalabs.h
  habanalabs: extend QMAN0 job timeout
  habanalabs: set DMA0 completion to SOB 1007
  habanalabs: fix validation of WREG32 to DMA completion
  habanalabs: fix mmu cache registers init
  habanalabs: disable CPU access on timeouts
  habanalabs: add MMU DRAM default page mapping
  habanalabs: Dissociate RAZWI info from event types
  misc/habanalabs: adjust Kconfig to fix build errors
  ...
</content>
</entry>
<entry>
<title>m68k: Dispatch nvram_ops calls to Atari or Mac functions</title>
<updated>2019-01-22T09:21:45Z</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2019-01-15T04:18:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d3b41b6bb49ecbf74b6bda63e00bf17fdb4d3c47'/>
<id>urn:sha1:d3b41b6bb49ecbf74b6bda63e00bf17fdb4d3c47</id>
<content type='text'>
A multi-platform kernel binary has to decide at run-time how to dispatch
the arch_nvram_ops calls. Add a platform-independent arch_nvram_ops
struct for this, to replace the atari-specific one.

Enable CONFIG_HAVE_ARCH_NVRAM_OPS for Macs.

Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>m68k/mac: Fix PRAM accessors</title>
<updated>2019-01-22T09:21:45Z</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2019-01-15T04:18:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aefcb7460e0b5f35f72601b7a98eec5ca1639cf2'/>
<id>urn:sha1:aefcb7460e0b5f35f72601b7a98eec5ca1639cf2</id>
<content type='text'>
PMU-based m68k Macs pre-date PowerMac-style NVRAM. Use the appropriate
PMU commands. Also implement the missing XPRAM accessors for VIA-based
Macs.

Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>m68k/mac: Use macros for RTC accesses not magic numbers</title>
<updated>2019-01-22T09:21:45Z</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2019-01-15T04:18:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a71fa0e3e5fc709f63bb70f73c9f26b38787d45d'/>
<id>urn:sha1:a71fa0e3e5fc709f63bb70f73c9f26b38787d45d</id>
<content type='text'>
This is intended to improve code style and not affect code behaviour.

Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>m68k/mac: Adopt naming and calling conventions for PRAM routines</title>
<updated>2019-01-22T09:21:45Z</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2019-01-15T04:18:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cda67df5942b02c9549287cdfd2495ae1a02246a'/>
<id>urn:sha1:cda67df5942b02c9549287cdfd2495ae1a02246a</id>
<content type='text'>
Adopt the existing *_read_byte and *_write_byte naming convention.
Rename via_pram_readbyte and via_pram_writebyte to avoid confusion.
Adjust calling conventions of mac_pram_* functions to match the
struct nvram_ops methods.

Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
