Finn Thain | 3 Jul 05:35 2015
Picon

[PATCH] char/nvram: Use bitwise OR to obtain Atari video mode data


Signed-off-by: Finn Thain <fthain <at> telegraphics.com.au>

Index: linux/drivers/char/nvram.c
===================================================================
--- linux.orig/drivers/char/nvram.c	2015-07-02 13:50:40.000000000 +1000
+++ linux/drivers/char/nvram.c	2015-07-02 14:00:05.000000000 +1000
 <at>  <at>  -702,7 +702,7  <at>  <at>  static void atari_proc_infos(unsigned ch
 		seq_printf(seq, "%ds%s\n", nvram[10],
 		    nvram[10] < 8 ? ", no memory test" : "");

-	vmode = (nvram[14] << 8) || nvram[15];
+	vmode = (nvram[14] << 8) | nvram[15];
 	seq_printf(seq,
 	    "Video mode       : %s colors, %d columns, %s %s monitor\n",
 	    colors[vmode & 7],

Klientskie bazi tel +79133913837 Email: nonen22pp <at> gmail.com Yznaite podrobnee!!!

Klientskie bazi tel +79133913837 Email: nonen22pp <at> gmail.com Yznaite podrobnee!!!
Sasnett_Karen | 1 Jul 13:53 2015

(unknown)


Haben Sie einen Investor brauchen?

Haben Sie geschäftliche oder persönliche Darlehen benötigen?

Wir geben Darlehen an eine natürliche Person und Unternehmen bei 3% Zinsen jährlich. Weitere
Informationen Kontaktieren Sie uns per E-Mail: omfcreditspa <at> hotmail.com<mailto:omfcreditspa <at> hotmail.com>

HINWEIS: Leiten Sie Ihre Antwort nur an diese E-Mail: omfcreditspa <at> hotmail.com<mailto:omfcreditspa <at> hotmail.com>
wenny_budi_p | 30 Jun 23:00 2015
Picon

LOAN OFFER


 Hello, do you need a business or personal loan interest rate of 3%? If interested, kindly get back to us with
the following information.
NAME OF BORROWER:
* COUNTRY:
* GENDER:
* OCCUPATION:
* MONTHLY INCOME:
* Loan Amount Required:
* Loan Duration:
* LOAN PURPOSE:
* PHONE NUMBERS:

wenny_budi_p | 30 Jun 16:10 2015
Picon

LOAN OFFER


 Hello, do you need a business or personal loan interest rate of 3%? If interested, kindly get back to us with
the following information.
NAME OF BORROWER:
* COUNTRY:
* GENDER:
* OCCUPATION:
* MONTHLY INCOME:
* Loan Amount Required:
* Loan Duration:
* LOAN PURPOSE:
* PHONE NUMBERS:

Finn Thain | 28 Jun 03:41 2015
Picon

[RFC v3 00/24] Re-use nvram module


The generic NVRAM module, drivers/char/generic_nvram, implements a
/dev/nvram misc device. It is used only by 32-bit PowerPC platforms and
isn't generic enough to be more widely used.

The RTC NVRAM module, drivers/char/nvram, also implements a /dev/nvram
misc device. It is used by x86, ARM and m68k.

The former module cannot be used on x86, ARM or m68k because it
cannot co-exist with the latter module, partly due to the Kconfig logic.

It is possible to modify the modules so that one kernel binary could
have either, neither or both. However, automatically loading the
appropriate module is then impossible; if both provide the
char-major-10-144 alias then the wrong module will end up being loaded.
Hence a multi-platform kernel binary needs a single generic nvram module
with alias char-major-10-144.

Therefore, drivers/char/nvram.c should be made more generic and the
arch-specific code therein should be moved to a more appropriate
place under arch/. Also, drivers/char/generic_nvram.c should be removed
to reduce code duplication.

In this patch series, Atari-specific code is moved from the nvram module
to arch/m68k/atari. More arch-specific code in the nvram module could
be moved, probably to arch/x86, but it is difficult to determine just
what code is relevant to ARM platforms and what code is x86-only.

In addressing code duplication, this patch series removes three
inconsistent /dev/nvram misc device implementations. One of these,
(Continue reading)

Geert Uytterhoeven | 22 Jun 09:35 2015

[git pull] m68k updates for 4.2

	Hi Linus,

The following changes since commit c65b99f046843d2455aa231747b5a07a999a9f3d:

  Linux 4.1-rc6 (2015-05-31 19:01:07 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-4.2

for you to fetch changes up to 1214c525484cabb27ed37df936c3451682757263:

  m68k: Use for_each_sg() (2015-06-01 10:36:29 +0200)

----------------------------------------------------------------
Akinobu Mita (1):
      m68k: Use for_each_sg()

Geert Uytterhoeven (1):
      m68k/defconfig: Update defconfigs for v4.1-rc6

 arch/m68k/configs/amiga_defconfig    |  8 ++++++--
 arch/m68k/configs/apollo_defconfig   |  8 ++++++--
 arch/m68k/configs/atari_defconfig    |  8 ++++++--
 arch/m68k/configs/bvme6000_defconfig |  8 ++++++--
 arch/m68k/configs/hp300_defconfig    |  8 ++++++--
 arch/m68k/configs/mac_defconfig      |  8 ++++++--
 arch/m68k/configs/multi_defconfig    |  8 ++++++--
 arch/m68k/configs/mvme147_defconfig  |  8 ++++++--
 arch/m68k/configs/mvme16x_defconfig  |  8 ++++++--
(Continue reading)

gerg | 19 Jun 03:13 2015

[PATCH] m68k: improve m68knommu MAINTAINERS entry

From: Greg Ungerer <gerg <at> uclinux.org>

Improve the information in the m68knommu maintainers entry. This
should aid in making it clearer what parts of the m68k architecture
code can go via the m68knommu git tree.

Specifically the entry now lists the relevant git tree where m68knommu
patches are promoted through. It also spells out that the coldfire
sub-architecture, and with it the directory of arch/m68k/coldfire, as
being supported via this tree.

Signed-off-by: Greg Ungerer <gerg <at> uclinux.org>
---
 MAINTAINERS | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index d8afd29..bd0090d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
 <at>  <at>  -10155,11 +10155,14  <at>  <at>  S:	Maintained
 F:	Documentation/filesystems/ubifs.txt
 F:	fs/ubifs/
 
-UCLINUX (AND M68KNOMMU)
+UCLINUX (M68KNOMMU AND COLDFIRE)
 M:	Greg Ungerer <gerg <at> uclinux.org>
 W:	http://www.uclinux.org/
+L:	linux-m68k <at> lists.linux-m68k.org
 L:	uclinux-dev <at> uclinux.org  (subscribers-only)
(Continue reading)

Stephen Boyd | 18 Jun 03:04 2015

Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain

On 10/06/2014 10:28 PM, Guenter Roeck wrote:
> Various drivers implement architecture and/or device specific means to
> remove power from the system.  For the most part, those drivers set the
> global variable pm_power_off to point to a function within the driver.
>
> This mechanism has a number of drawbacks.  Typically only one scheme
> to remove power is supported (at least if pm_power_off is used).
> At least in theory there can be multiple means remove power, some of
> which may be less desirable. For example, some mechanisms may only
> power off the CPU or the CPU card, while another may power off the
> entire system.  Others may really just execute a restart sequence
> or drop into the ROM monitor. Using pm_power_off can also be racy
> if the function pointer is set from a driver built as module, as the
> driver may be in the process of being unloaded when pm_power_off is
> called. If there are multiple poweroff handlers in the system, removing
> a module with such a handler may inadvertently reset the pointer to
> pm_power_off to NULL, leaving the system with no means to remove power.
>
> Introduce a system poweroff handler call chain to solve the described
> problems.  This call chain is expected to be executed from the
> architecture specific machine_power_off() function.  Drivers providing
> system poweroff functionality are expected to register with this call chain.
> By using the priority field in the notifier block, callers can control
> poweroff handler execution sequence and thus ensure that the poweroff
> handler with the optimal capabilities to remove power for a given system
> is called first.

What happened to this series? I want to add shutdown support to my
platform and I need to write a register on the PMIC in one driver to
configure it for shutdown instead of restart and then write an MMIO
(Continue reading)

Joe Perches | 15 Jun 04:01 2015

[PATCH] m68k: Use vsprintf %pM extension

Format mac addresses with the normal kernel extension.

Signed-off-by: Joe Perches <joe <at> perches.com>
---
 arch/m68k/68000/m68EZ328.c | 3 +--
 arch/m68k/68000/m68VZ328.c | 3 +--
 arch/m68k/68360/config.c   | 3 +--
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/m68k/68000/m68EZ328.c b/arch/m68k/68000/m68EZ328.c
index 2195290..e6ab321 100644
--- a/arch/m68k/68000/m68EZ328.c
+++ b/arch/m68k/68000/m68EZ328.c
 <at>  <at>  -62,8 +62,7  <at>  <at>  void __init config_BSP(char *command, int len)
 #ifdef CONFIG_UCSIMM
   printk(KERN_INFO "uCsimm serial string [%s]\n",getserialnum());
   p = cs8900a_hwaddr = gethwaddr(0);
-  printk(KERN_INFO "uCsimm hwaddr %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
-         p[0], p[1], p[2], p[3], p[4], p[5]);
+  printk(KERN_INFO "uCsimm hwaddr %pM\n", p);

   p = getbenv("APPEND");
   if (p) strcpy(p,command);
diff --git a/arch/m68k/68000/m68VZ328.c b/arch/m68k/68000/m68VZ328.c
index 0e5e5a1..1154bdb 100644
--- a/arch/m68k/68000/m68VZ328.c
+++ b/arch/m68k/68000/m68VZ328.c
 <at>  <at>  -152,8 +152,7  <at>  <at>  static void __init init_hardware(char *command, int size)

 	printk(KERN_INFO "uCdimm serial string [%s]\n", getserialnum());
(Continue reading)

Finn Thain | 14 Jun 09:46 2015
Picon

[RFC v2 00/24] Re-use nvram module


The generic NVRAM module, drivers/char/generic_nvram, implements a
/dev/nvram misc device. It is used only by 32-bit PowerPC platforms and
isn't generic enough to be more widely used.

The RTC NVRAM module, drivers/char/nvram, also implements a /dev/nvram
misc device. It is used by x86, ARM and m68k.

The former module cannot be used on x86, ARM or m68k because it
cannot co-exist with the latter module, partly due to the Kconfig logic.

It is possible to modify the modules so that one kernel binary could
have either, neither or both. However, automatically loading the
appropriate module is then impossible; if both provide the
char-major-10-144 alias then the wrong module will end up being loaded.
Hence a multi-platform kernel binary needs a single generic nvram module
with alias char-major-10-144.

Therefore, drivers/char/nvram.c should be made more generic and the
arch-specific code therein should be moved to a more appropriate
place under arch/. Also, drivers/char/generic_nvram.c should be removed
to reduce code duplication.

In this patch series, Atari-specific code is moved from the nvram module
to arch/m68k/atari. More arch-specific code in the nvram module could
be moved, probably to arch/x86, but it is difficult to determine just
what code is relevant to ARM platforms and what code is x86-only.

In addressing code duplication, this patch series removes three
inconsistent /dev/nvram misc device implementations. One of these,
(Continue reading)


Gmane