Re: linux-m68k archival at lore.kernel.org
On Tue, 22 Oct 2019, Geert Uytterhoeven wrote: > > > Note that sanitization script choked on some mails from the old > > > phil.uni-sb.de list, so it didn't succeed for me. > > > > Was that the "From" bug? I am experimenting with pre-processing of > > mboxes to substitute the "From" lines in the message bodies. Not yet > > sure if this will be entirely successful... > > Possibly, my old archives were stored in Alpine mboxes. > Here are some variations on the From issue: 1) in Message-ID: <4b8e6d6a.6050...@codesourcery.com>, I find that the attachment begins with an "escaped From": >From de4c0f12fd2fd3e8436218dfb5edba3b3d570ee0 Mon Sep 17 00:00:00 2001 I don't think alpine did this. I think it was sent that way. 2) in Message-ID: which is missing from your archive, there is this line: From . 3) in Message-ID: <20090112105942.ga10...@uranus.ravnborg.org> which is in your archive, there is this line: From the outside it looks like there are indeed a whish to do so (I added the tab indentation to avoid even more MUA escapades.) Now look what happened to 3) when it reached lore.kernel.org: https://lore.kernel.org/lkml/20090112105942.ga10...@uranus.ravnborg.org/ Note that the escape now shows up in the html! The original (according to alpine) has no ">From the outside", instead it has "From the outside". That means that if I insert a ">" into message 2) above, to "escape" the "From" and make the importer is happy, then lore.kernel.org will incorrectly render that escape. Similarly, Alpine will also render that modification as ">From" because it doesn't recognize the so-called "escape". And if I don't do that, the importer will truncate the message... --
Re: linux-m68k archival at lore.kernel.org
Hi Finn,
On Tue, Oct 22, 2019 at 12:42 AM Finn Thain wrote:
> On Sun, 20 Oct 2019, Geert Uytterhoeven wrote:
> > I'm working to add this list to lore.kernel.org.
>
> That's great news because lore.kernel.org is a search engine that actually
> works.
Yes, and recently, lots of commits gained Link: tags, so as soon as the
archive is populated, those will start working (they already do if e.g. lkml
was CCed on the original patch posting).
> > As one of prerequisites they require that we provide full existing
> > archives of all list messages (or, at least, as complete as possible).
> > I've collected mine already, but would really appreciate if you could
> > pitch in from your own collection.
> >
> > Just follow the instructions on this page:
> > https://korg.wiki.kernel.org/userdoc/lore
> >
>
> For anyone else attempting this, note that linux-m68k has two addresses,
> so you need to pass two '-l' parameters:
> -l linux-m68k.vger.kernel.org linux-m68k.lists.linux-m68k.org
Correct.
> The above wiki page neglects to mention that the 'list-archive-maker.py'
> script has serious problems.
I'd say: ignore that script.
> Another problem with that script is that it captures too much. It will
> grab messages that appear to be cross-posted (based on To: or Cc:) even if
> those messages never reached linux-m68k. I suppose the idea is that
> capturing too much is better than too little?
I think that's intentional: when CCing multiple lists, possibly with a personal
CC too, people may have stored a single copy of the received email only,
while you still want it in the archive.
Still, one might question why those messages never reached the list...
> > My archive should be fairly complete, except for network outages, and e.g.
> > the Gandi email disaster week 2 years ago. And I don't have anything from
> > the real early days, unfortunately.
>
> I'll let you know if I find any missing messages here
Thanks!
Please note that I discovered that something went wrong when creating
export-linux-m68k-vger.kernel.org2.mbox, so it lacks some emails I do have.
I uploaded those IDs to an additional file (84 IDs):
http://users.telenet.be/geertu/export-linux-m68k-vger.kernel.org2.id.extra.xz
> > Note that sanitization script choked on some mails from the old
> > phil.uni-sb.de list, so it didn't succeed for me.
>
> Was that the "From" bug? I am experimenting with pre-processing of mboxes
> to substitute the "From" lines in the message bodies. Not yet sure if this
> will be entirely successful...
Possibly, my old archives were stored in Alpine mboxes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: linux-m68k archival at lore.kernel.org
On Sun, 20 Oct 2019, Geert Uytterhoeven wrote:
> Hi all,
>
> I'm working to add this list to lore.kernel.org.
That's great news because lore.kernel.org is a search engine that actually
works.
> As one of prerequisites they require that we provide full existing
> archives of all list messages (or, at least, as complete as possible).
> I've collected mine already, but would really appreciate if you could
> pitch in from your own collection.
>
> Just follow the instructions on this page:
> https://korg.wiki.kernel.org/userdoc/lore
>
For anyone else attempting this, note that linux-m68k has two addresses,
so you need to pass two '-l' parameters:
-l linux-m68k.vger.kernel.org linux-m68k.lists.linux-m68k.org
The above wiki page neglects to mention that the 'list-archive-maker.py'
script has serious problems.
It can't deal with Alpine mboxes because they don't mangle "From" in
message bodies as ">From". This leads to truncated messages.
I strongly recommend that you enable the '-r' parameter and then examine
all of the rejected messages.
You'll also need to edit the script to avoid capturing rejected messages
that they were rejected for obvious reasons (wrong list-id) rather than
messed-up message boundary (i.e. a 'From ' mistakenly used as a message
delimiter).
Another problem with that script is that it captures too much. It will
grab messages that appear to be cross-posted (based on To: or Cc:) even if
those messages never reached linux-m68k. I suppose the idea is that
capturing too much is better than too little?
The script fabicates a missing List-ID header based on a guess. I don't
know why it does this (bad idea from an archival perspective).
> I uploaded the list of message-ids that I already have to
> http://users.telenet.be/geertu/linux-m68k-message-ids.tar.xz
> You'll need it during the archive sanitization process to pass to the -k
> switch.
>
> Please tar up and xz -9 the resulting directory with mbox files and send
> the archive to me so I can add it to what I already have.
>
> The archives I used, from my personal email collection, are:
> 1. linux-activi...@niksula.hut.fi 680x0 channel digest (May 1993 - March
> 1995)
> Used initially. Probably there was never a non-digest version?
> 2. linux-68...@vger.rutgers.edu (Dec 1994 - Dec 1995)
> First real mailing list. Abandoned due to latency (most developers were
> located in Europe and 2 Mbps transatlantic sucked).
> 3. linux-m...@phil.uni-sb.de (Oct 1995 - Oct 2004)
> Second mailing list. Abandoned due to spam and lack of admin activity.
> I did my best to remove spam.
> 4. linux-m68k@vger.kernel.org (Oct 2004 - Current)
> Current mailing list.
> As this is a single logical mailing list, the plan is to combine all of
> it in a single archive.
>
> My archive should be fairly complete, except for network outages, and e.g.
> the Gandi email disaster week 2 years ago. And I don't have anything from
> the real early days, unfortunately.
>
I'll let you know if I find any missing messages here
> Note that sanitization script choked on some mails from the old
> phil.uni-sb.de list, so it didn't succeed for me.
>
Was that the "From" bug? I am experimenting with pre-processing of mboxes
to substitute the "From" lines in the message bodies. Not yet sure if this
will be entirely successful...
--
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
>
linux-m68k archival at lore.kernel.org
Hi all,
I'm working to add this list to lore.kernel.org. As one of prerequisites
they require that we provide full existing archives of all list messages
(or, at least, as complete as possible). I've collected mine already, but
would really appreciate if you could pitch in from your own collection.
Just follow the instructions on this page:
https://korg.wiki.kernel.org/userdoc/lore
I uploaded the list of message-ids that I already have to
http://users.telenet.be/geertu/linux-m68k-message-ids.tar.xz
You'll need it during the archive sanitization process to pass to the -k switch.
Please tar up and xz -9 the resulting directory with mbox files and send
the archive to me so I can add it to what I already have.
The archives I used, from my personal email collection, are:
1. linux-activi...@niksula.hut.fi 680x0 channel digest (May 1993 - March 1995)
Used initially. Probably there was never a non-digest version?
2. linux-68...@vger.rutgers.edu (Dec 1994 - Dec 1995)
First real mailing list. Abandoned due to latency (most developers were
located in Europe and 2 Mbps transatlantic sucked).
3. linux-m...@phil.uni-sb.de (Oct 1995 - Oct 2004)
Second mailing list. Abandoned due to spam and lack of admin activity.
I did my best to remove spam.
4. linux-m68k@vger.kernel.org (Oct 2004 - Current)
Current mailing list.
As this is a single logical mailing list, the plan is to combine all of it in a
single archive.
My archive should be fairly complete, except for network outages, and e.g.
the Gandi email disaster week 2 years ago. And I don't have anything from
the real early days, unfortunately.
Note that sanitization script choked on some mails from the old phil.uni-sb.de
list, so it didn't succeed for me.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Apply For Financial investment at a lower rate 2%
-- Hello, We are private lenders based in UK. Do you need a loan (credit) as soon as possible. Are you in search of money to solve your personal needs or finance your business venture, then get Your desired loan today! Consult us at Sunrise Funding Ltd. * We offer personal loan & huge capital loan at 2% interest rate to the general public both locally and internationally. * Credit amount range from $5,000.00 -- $500,000.00 and above. * Special $10,000,000.00 Loan offer for huge project also available. * Loan period of 6 months -- 10 years. * Loan is granted 24 hours after approval and accredited, directly in hand or bank account. Please note that you are advised to contact us for more details via the following e-mail address below; EMAIL : sunrisefundinglt...@gmail.com FIRM : Sunrise Funding Ltd UK.
RE:PERSONAL LETTER FROM MRS RASHIA AMIRA
Greetings My name is Barrister Hans Erich. I have a client who is interested to invest in your country, she is a well known politician in her country and deserve a lucrative investment partnership with you outside her country without any delay Please can you manage such investment please Kindly reply for further details. Your full names Your urgent response will be appreciated Thank you and God bless you. Barrister Hans Erich Yours sincerely, Barrister Hans Erich CONTACT: hanserich9hel...@gmail.com
Re: [PATCH] Remove every trace of SERIAL_MAGIC
[ Sorry, for previous HTML email, trying to send patches from work machine for the first time, re-sending in text ] On Fri, 4 Oct 2019 at 14:29, John Paul Adrian Glaubitz wrote: > > On 10/4/19 3:20 PM, Pascal Terjan wrote: > > The only code mentioning it doesn't build (and hasn't at least since git) > > and doesn't include the header defining it. > What do you mean, amiserial doesn't build? The code doesn't build if enabling the "option" SERIAL_PARANOIA_CHECK in the file, this patch is removing that option and he code protected by it > root@elgar:~> grep AMIGA_BUILTIN_SERIAL /boot/config-$(uname -r) > CONFIG_AMIGA_BUILTIN_SERIAL=y > root@elgar:~> > > root@elgar:~> uname -a > Linux elgar 5.2.0-2-m68k #1 Debian 5.2.9-2 (2019-08-21) m68k GNU/Linux > root@elgar:~> > > We're using this driver, it works just fine. > > And I'm not sure what SERIAL_MAGIC does. Is that for > CONFIG_MAGIC_SYSRQ_SERIAL? It used to be a magic number in the struct to verify you are getting the expected object > Because we still use that, too. Although I haven't tested it for a while but > I'm using the serial console on my Amiga 4000 right now using amiserial.c. >
Re: [PATCH] Remove every trace of SERIAL_MAGIC
On 10/4/19 3:31 PM, Pascal Terjan wrote: > On 10/4/19 3:20 PM, Pascal Terjan wrote: > > The only code mentioning it doesn't build (and hasn't at least since > git) > > and doesn't include the header defining it. > What do you mean, amiserial doesn't build? > > > The code doesn't build if enabling the "option" SERIAL_PARANOIA_CHECK in the > file, this patch is removing that option and he code protected by it Okay, so apparently what this does is checking whether any "struct serial_state *info" passed to the driver contains the correct SERIAL_MAGIC in info->magic and if not, prints a warning to the kernel buffer. I have no idea what this being used for. Maybe Geert can comment on this. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] Remove every trace of SERIAL_MAGIC
On 10/4/19 3:20 PM, Pascal Terjan wrote: > The only code mentioning it doesn't build (and hasn't at least since git) > and doesn't include the header defining it. What do you mean, amiserial doesn't build? root@elgar:~> grep AMIGA_BUILTIN_SERIAL /boot/config-$(uname -r) CONFIG_AMIGA_BUILTIN_SERIAL=y root@elgar:~> root@elgar:~> uname -a Linux elgar 5.2.0-2-m68k #1 Debian 5.2.9-2 (2019-08-21) m68k GNU/Linux root@elgar:~> We're using this driver, it works just fine. And I'm not sure what SERIAL_MAGIC does. Is that for CONFIG_MAGIC_SYSRQ_SERIAL? Because we still use that, too. Although I haven't tested it for a while but I'm using the serial console on my Amiga 4000 right now using amiserial.c. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] Remove every trace of SERIAL_MAGIC
On Fri, Oct 04, 2019 at 02:20:01PM +0100, Pascal Terjan wrote: > The only code mentioning it doesn't build (and hasn't at least since git) > and doesn't include the header defining it. > > This means removing support for checking magic in amiserial.c > (SERIAL_PARANOIA_CHECK option), which was checking a magic field which > doesn't currently exist in the struct. > > Signed-off-by: Pascal Terjan > --- > Documentation/process/magic-number.rst| 1 - > .../it_IT/process/magic-number.rst| 1 - > .../zh_CN/process/magic-number.rst| 1 - > drivers/net/wan/z85230.h | 2 - > drivers/tty/amiserial.c | 81 +-- > 5 files changed, 1 insertion(+), 85 deletions(-) What changed from the first version? Always version your patches and properly put what changed below the --- line. Like the documentation says to do :) v3 please? thanks, greg k-h
[PATCH] Remove every trace of SERIAL_MAGIC
The only code mentioning it doesn't build (and hasn't at least since git)
and doesn't include the header defining it.
This means removing support for checking magic in amiserial.c
(SERIAL_PARANOIA_CHECK option), which was checking a magic field which
doesn't currently exist in the struct.
Signed-off-by: Pascal Terjan
---
Documentation/process/magic-number.rst| 1 -
.../it_IT/process/magic-number.rst| 1 -
.../zh_CN/process/magic-number.rst| 1 -
drivers/net/wan/z85230.h | 2 -
drivers/tty/amiserial.c | 81 +--
5 files changed, 1 insertion(+), 85 deletions(-)
diff --git a/Documentation/process/magic-number.rst
b/Documentation/process/magic-number.rst
index 547bbf28e615..eee9b44553b3 100644
--- a/Documentation/process/magic-number.rst
+++ b/Documentation/process/magic-number.rst
@@ -81,7 +81,6 @@ FF_MAGIC 0x4646 fc_info
``drivers/net/ip
ISICOM_MAGIC 0x4d54 isi_port
``include/linux/isicom.h``
PTY_MAGIC 0x5001
``drivers/char/pty.c``
PPP_MAGIC 0x5002 ppp
``include/linux/if_pppvar.h``
-SERIAL_MAGIC 0x5301 async_struct
``include/linux/serial.h``
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
diff --git a/Documentation/translations/it_IT/process/magic-number.rst
b/Documentation/translations/it_IT/process/magic-number.rst
index ed1121d0ba84..783e0de314a0 100644
--- a/Documentation/translations/it_IT/process/magic-number.rst
+++ b/Documentation/translations/it_IT/process/magic-number.rst
@@ -87,7 +87,6 @@ FF_MAGIC 0x4646 fc_info
``drivers/net/ip
ISICOM_MAGIC 0x4d54 isi_port
``include/linux/isicom.h``
PTY_MAGIC 0x5001
``drivers/char/pty.c``
PPP_MAGIC 0x5002 ppp
``include/linux/if_pppvar.h``
-SERIAL_MAGIC 0x5301 async_struct
``include/linux/serial.h``
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
diff --git a/Documentation/translations/zh_CN/process/magic-number.rst
b/Documentation/translations/zh_CN/process/magic-number.rst
index 15c592518194..e4c225996af0 100644
--- a/Documentation/translations/zh_CN/process/magic-number.rst
+++ b/Documentation/translations/zh_CN/process/magic-number.rst
@@ -70,7 +70,6 @@ FF_MAGIC 0x4646 fc_info
``drivers/net/ip
ISICOM_MAGIC 0x4d54 isi_port
``include/linux/isicom.h``
PTY_MAGIC 0x5001
``drivers/char/pty.c``
PPP_MAGIC 0x5002 ppp
``include/linux/if_pppvar.h``
-SERIAL_MAGIC 0x5301 async_struct
``include/linux/serial.h``
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
diff --git a/drivers/net/wan/z85230.h b/drivers/net/wan/z85230.h
index 32ae710d4f40..1081d171e477 100644
--- a/drivers/net/wan/z85230.h
+++ b/drivers/net/wan/z85230.h
@@ -421,8 +421,6 @@ extern struct z8530_irqhandler z8530_sync, z8530_async,
z8530_nop;
* Asynchronous Interfacing
*/
-#define SERIAL_MAGIC 0x5301
-
/*
* The size of the serial xmit buffer is 1 page, or 4096 bytes
*/
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index 8330fd809a05..0af81a82df8f 100644
--- a/drivers/tty/amiserial.c
+++ b/drivers/tty/amiserial.c
@@ -23,17 +23,12 @@
*/
/*
- * Serial driver configuration section. Here are the various options:
+ * Serial driver configuration section.
*
- * SERIAL_PARANOIA_CHECK
- * Check the magic number for the async_structure where
- * ever possible.
*/
#include
-#undef SERIAL_PARANOIA_CHECK
-
/* Set of debugging defines */
#undef SERIAL_DEBUG_INTR
@@ -132,28 +127,6 @@ static struct serial_state rs_table[1];
#define serial_isroot()(capable(CAP_SYS_ADMIN))
-
-static inline int serial_paranoia_check(struct serial_state *info,
- char *name, const char *routine)
-{
-#ifdef SERIAL_PARANOIA_CHECK
- static const char
Re: [PATCH] Remove every trace of SERIAL_MAGIC
On Fri, Sep 27, 2019 at 10:55:24PM +0200, Pascal Terjan wrote: > The only code mentioning it doesn't build (and hasn't at least since git) > and doesn't include the header defining it. > > This means removing support for checking magic in amiserial.c > (SERIAL_PARANOIA_CHECK option), which was checking a magic field which > doesn't currently exist in the struct. > --- > Documentation/process/magic-number.rst| 1 - > .../it_IT/process/magic-number.rst| 1 - > .../zh_CN/process/magic-number.rst| 1 - > drivers/net/wan/z85230.h | 2 - > drivers/tty/amiserial.c | 81 +-- > 5 files changed, 1 insertion(+), 85 deletions(-) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch does not have a Signed-off-by: line. Please read the kernel file, Documentation/SubmittingPatches and resend it after adding that line. Note, the line needs to be in the body of the email, before the patch, not at the bottom of the patch or in the email signature. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
[PATCH] Remove every trace of SERIAL_MAGIC
The only code mentioning it doesn't build (and hasn't at least since git)
and doesn't include the header defining it.
This means removing support for checking magic in amiserial.c
(SERIAL_PARANOIA_CHECK option), which was checking a magic field which
doesn't currently exist in the struct.
---
Documentation/process/magic-number.rst| 1 -
.../it_IT/process/magic-number.rst| 1 -
.../zh_CN/process/magic-number.rst| 1 -
drivers/net/wan/z85230.h | 2 -
drivers/tty/amiserial.c | 81 +--
5 files changed, 1 insertion(+), 85 deletions(-)
diff --git a/Documentation/process/magic-number.rst
b/Documentation/process/magic-number.rst
index 547bbf28e615..eee9b44553b3 100644
--- a/Documentation/process/magic-number.rst
+++ b/Documentation/process/magic-number.rst
@@ -81,7 +81,6 @@ FF_MAGIC 0x4646 fc_info
``drivers/net/ip
ISICOM_MAGIC 0x4d54 isi_port
``include/linux/isicom.h``
PTY_MAGIC 0x5001
``drivers/char/pty.c``
PPP_MAGIC 0x5002 ppp
``include/linux/if_pppvar.h``
-SERIAL_MAGIC 0x5301 async_struct
``include/linux/serial.h``
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
diff --git a/Documentation/translations/it_IT/process/magic-number.rst
b/Documentation/translations/it_IT/process/magic-number.rst
index ed1121d0ba84..783e0de314a0 100644
--- a/Documentation/translations/it_IT/process/magic-number.rst
+++ b/Documentation/translations/it_IT/process/magic-number.rst
@@ -87,7 +87,6 @@ FF_MAGIC 0x4646 fc_info
``drivers/net/ip
ISICOM_MAGIC 0x4d54 isi_port
``include/linux/isicom.h``
PTY_MAGIC 0x5001
``drivers/char/pty.c``
PPP_MAGIC 0x5002 ppp
``include/linux/if_pppvar.h``
-SERIAL_MAGIC 0x5301 async_struct
``include/linux/serial.h``
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
diff --git a/Documentation/translations/zh_CN/process/magic-number.rst
b/Documentation/translations/zh_CN/process/magic-number.rst
index 15c592518194..e4c225996af0 100644
--- a/Documentation/translations/zh_CN/process/magic-number.rst
+++ b/Documentation/translations/zh_CN/process/magic-number.rst
@@ -70,7 +70,6 @@ FF_MAGIC 0x4646 fc_info
``drivers/net/ip
ISICOM_MAGIC 0x4d54 isi_port
``include/linux/isicom.h``
PTY_MAGIC 0x5001
``drivers/char/pty.c``
PPP_MAGIC 0x5002 ppp
``include/linux/if_pppvar.h``
-SERIAL_MAGIC 0x5301 async_struct
``include/linux/serial.h``
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
diff --git a/drivers/net/wan/z85230.h b/drivers/net/wan/z85230.h
index 32ae710d4f40..1081d171e477 100644
--- a/drivers/net/wan/z85230.h
+++ b/drivers/net/wan/z85230.h
@@ -421,8 +421,6 @@ extern struct z8530_irqhandler z8530_sync, z8530_async,
z8530_nop;
* Asynchronous Interfacing
*/
-#define SERIAL_MAGIC 0x5301
-
/*
* The size of the serial xmit buffer is 1 page, or 4096 bytes
*/
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index 8330fd809a05..0af81a82df8f 100644
--- a/drivers/tty/amiserial.c
+++ b/drivers/tty/amiserial.c
@@ -23,17 +23,12 @@
*/
/*
- * Serial driver configuration section. Here are the various options:
+ * Serial driver configuration section.
*
- * SERIAL_PARANOIA_CHECK
- * Check the magic number for the async_structure where
- * ever possible.
*/
#include
-#undef SERIAL_PARANOIA_CHECK
-
/* Set of debugging defines */
#undef SERIAL_DEBUG_INTR
@@ -132,28 +127,6 @@ static struct serial_state rs_table[1];
#define serial_isroot()(capable(CAP_SYS_ADMIN))
-
-static inline int serial_paranoia_check(struct serial_state *info,
- char *name, const char *routine)
-{
-#ifdef SERIAL_PARANOIA_CHECK
- static const char *badmagic =
- "Warning:
[PATCH RESEND v2 2/2] drivers/ata: convert pata_falcon to arch platform device
The Atari platform device setup now provides a platform device
for the Falcon IDE interface. Use this in place of the simple platform
device set up in the old pata_falcon probe code.
Signed-off-by: Michael Schmitz
--
Changes from v1
- drop obsolete ATA_HD_BASE define
- use dev_err() to report error obtaining platform resource
---
drivers/ata/pata_falcon.c | 42 --
1 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/ata/pata_falcon.c b/drivers/ata/pata_falcon.c
index 41e0d6a..0e6c6b6 100644
--- a/drivers/ata/pata_falcon.c
+++ b/drivers/ata/pata_falcon.c
@@ -33,7 +33,6 @@
#define DRV_NAME "pata_falcon"
#define DRV_VERSION "0.1.0"
-#define ATA_HD_BASE0xfff0
#define ATA_HD_CONTROL 0x39
static struct scsi_host_template pata_falcon_sht = {
@@ -120,24 +119,22 @@ static int pata_falcon_set_mode(struct ata_link *link,
.set_mode = pata_falcon_set_mode,
};
-static int pata_falcon_init_one(void)
+static int __init pata_falcon_init_one(struct platform_device *pdev)
{
+ struct resource *res;
struct ata_host *host;
struct ata_port *ap;
- struct platform_device *pdev;
void __iomem *base;
- if (!MACH_IS_ATARI || !ATARIHW_PRESENT(IDE))
- return -ENODEV;
-
- pr_info(DRV_NAME ": Atari Falcon PATA controller\n");
+ dev_info(>dev, ": Atari Falcon PATA controller\n");
- pdev = platform_device_register_simple(DRV_NAME, 0, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
- if (!devm_request_mem_region(>dev, ATA_HD_BASE, 0x40, DRV_NAME)) {
- pr_err(DRV_NAME ": resources busy\n");
+ if (!devm_request_mem_region(>dev, res->start,
+resource_size(res), DRV_NAME)) {
+ dev_err(>dev, "resources busy\n");
return -EBUSY;
}
@@ -152,7 +149,7 @@ static int pata_falcon_init_one(void)
ap->flags |= ATA_FLAG_SLAVE_POSS | ATA_FLAG_NO_IORDY;
ap->flags |= ATA_FLAG_PIO_POLLING;
- base = (void __iomem *)ATA_HD_BASE;
+ base = (void __iomem *)res->start;
ap->ioaddr.data_addr= base;
ap->ioaddr.error_addr = base + 1 + 1 * 4;
ap->ioaddr.feature_addr = base + 1 + 1 * 4;
@@ -174,9 +171,26 @@ static int pata_falcon_init_one(void)
return ata_host_activate(host, 0, NULL, 0, _falcon_sht);
}
-module_init(pata_falcon_init_one);
+static int __exit pata_falcon_remove_one(struct platform_device *pdev)
+{
+ struct ata_host *host = platform_get_drvdata(pdev);
+
+ ata_host_detach(host);
+
+ return 0;
+}
+
+static struct platform_driver pata_falcon_driver = {
+ .remove = __exit_p(pata_falcon_remove_one),
+ .driver = {
+ .name = "atari-falcon-ide",
+ },
+};
+
+module_platform_driver_probe(pata_falcon_driver, pata_falcon_init_one);
MODULE_AUTHOR("Bartlomiej Zolnierkiewicz");
MODULE_DESCRIPTION("low-level driver for Atari Falcon PATA");
MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:atari-falcon-ide");
MODULE_VERSION(DRV_VERSION);
--
1.7.0.4
[PATCH RESEND v2 1/2] m68k/atari: add platform device for Falcon IDE port
Autoloading of Falcon IDE driver modules requires converting
these drivers to platform drivers.
Add platform device for Falcon IDE interface in Atari platform
setup code in preparation for this.
Signed-off-by: Michael Schmitz
--
Changes from RFC
- fix region size (spotted by Szymon Bieganski )
- define IDE interface address in atari/config.c, create platform device
always (suggested by Geert Uytterhoeven )
Changes from v1
- add error checking for Falcon IDE platform device register
---
arch/m68k/atari/config.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/atari/config.c b/arch/m68k/atari/config.c
index ca8469e..d6e9363 100644
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -896,8 +896,28 @@ static void isp1160_delay(struct device *dev, int delay)
};
#endif
+/*
+ * Falcon IDE interface
+ */
+
+#define FALCON_IDE_BASE0xfff0
+
+static const struct resource atari_falconide_rsrc[] __initconst = {
+ {
+ .flags = IORESOURCE_MEM,
+ .start = FALCON_IDE_BASE,
+ .end = FALCON_IDE_BASE+0x39,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = IRQ_MFP_FSCSI,
+ .end = IRQ_MFP_FSCSI,
+ },
+};
+
int __init atari_platform_init(void)
{
+ struct platform_device *pdev;
int rv = 0;
if (!MACH_IS_ATARI)
@@ -939,6 +959,13 @@ int __init atari_platform_init(void)
atari_scsi_tt_rsrc, ARRAY_SIZE(atari_scsi_tt_rsrc));
#endif
+ if (ATARIHW_PRESENT(IDE)) {
+ pdev = platform_device_register_simple("atari-falcon-ide", -1,
+ atari_falconide_rsrc, ARRAY_SIZE(atari_falconide_rsrc));
+ if (IS_ERR(pdev))
+ rv = PTR_ERR(pdev);
+ }
+
return rv;
}
--
1.7.0.4
[PATCH RESEND v2 0/2] Convert Atari Falcon IDE driver to platform device
[Resend because linux-m68k was dropped from the recipient list ...] As suggested by Geert, at least one of the drivers available for the Falcon IDE interface should be converted to a platform device driver (to enable module autoloading by the Debian installer). Add platform device for Falcon IDE (patch 1), and rewrite the present libata driver to make use of that device (patch 2). Changes from v1: Incorporated review comments by Geert; corrected silly mismatch between platform device name and platform driver name that caused loading driver to fail locating the related resource; check return code of platform device register call. Tested on ARAnyM with only the pata_falcon driver builtin. Cheers, Michael
Re: [PATCH 2/2] drivers/ata: convert pata_falcon to arch platform device
Hi Geert,
thanks for your feedback!
Am 04.09.2019 um 00:44 schrieb Geert Uytterhoeven:
Hi Michael,
On Tue, Jul 2, 2019 at 12:02 AM Michael Schmitz wrote:
The Atari platform device setup now provides a platform device
for the Falcon IDE interface. Use this in place of the simple platform
device set up in the old pata_falcon probe code.
Signed-off-by: Michael Schmitz
Thanks for your patch!
--- a/drivers/ata/pata_falcon.c
+++ b/drivers/ata/pata_falcon.c
@@ -120,23 +120,21 @@ static int pata_falcon_set_mode(struct ata_link *link,
.set_mode = pata_falcon_set_mode,
};
-static int pata_falcon_init_one(void)
+static int __init pata_falcon_init_one(struct platform_device *pdev)
{
+ struct resource *res;
struct ata_host *host;
struct ata_port *ap;
- struct platform_device *pdev;
void __iomem *base;
- if (!MACH_IS_ATARI || !ATARIHW_PRESENT(IDE))
- return -ENODEV;
-
- pr_info(DRV_NAME ": Atari Falcon PATA controller\n");
+ dev_info(>dev, ": Atari Falcon PATA controller\n");
- pdev = platform_device_register_simple(DRV_NAME, 0, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
- if (!devm_request_mem_region(>dev, ATA_HD_BASE, 0x40, DRV_NAME)) {
ATA_HD_BASE is now unused, and can be removed.
Right - well spotted!
+ if (!devm_request_mem_region(>dev, res->start,
+resource_size(res), DRV_NAME)) {
pr_err(DRV_NAME ": resources busy\n");
dev_err(>dev, "resources busy\n");
I stole that from pata_gayle, Bartlomiej may want to fix it there as well?
return -EBUSY;
}
@@ -174,9 +172,26 @@ static int pata_falcon_init_one(void)
return ata_host_activate(host, 0, NULL, 0, _falcon_sht);
}
-module_init(pata_falcon_init_one);
+static int __exit pata_falcon_remove_one(struct platform_device *pdev)
+{
+ struct ata_host *host = platform_get_drvdata(pdev);
+
+ ata_host_detach(host);
+
+ return 0;
+}
+
+static struct platform_driver pata_falcon_driver = {
+ .remove = __exit_p(pata_falcon_remove_one),
+ .driver = {
+ .name = "atari-falcon-ide",
+ },
+};
+
+module_platform_driver_probe(pata_falcon_driver, pata_falcon_init_one);
This doesn't seem to work in the builtin case (e.g. atari_defconfig with
ide replaced by ata): no hard drives are detected.
Due to a dumb naming mismatch between driver and platform code
(shouldn't have rushed this right before going on leave). This would
have made the driver fail in the modular case as well.
I'll fix that along with adding some error checking in the Atari
platform init code.
Regarding the potential bisection issue with this series - that ought to
be fixed as well by renaming the platform resource to match what the new
driver expects. I'd rather leave the two patches separate so the Atari
platform code one can go through your tree.
Cheers,
Michael
Gr{oetje,eeting}s,
Geert
Re: Kernel 5.3.0 stuck during boot on Amiga
Hi Adrian,
On Thu, Sep 19, 2019 at 8:44 PM John Paul Adrian Glaubitz
wrote:
> On 9/18/19 6:45 PM, Andreas Schwab wrote:
> >>> Is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS enabled?
> >>
> >> No:
> >>
> >> root@elgar:~> grep CONFIG_CRYPTO_MANAGER_DISABLE_TESTS
> >> /boot/config-$(uname -r)
> >> # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> >> root@elgar:~>
> >
> > Try enabling it.
> Okay, it indeed helps. Just opened a PR for the Debian kernel:
Thanks for checking!
> > https://salsa.debian.org/kernel-team/linux/merge_requests/171
Shouldn't this be enabled for all architectures?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Kernel 5.3.0 stuck during boot on Amiga
On 9/18/19 6:45 PM, Andreas Schwab wrote: Is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS enabled? No: root@elgar:~> grep CONFIG_CRYPTO_MANAGER_DISABLE_TESTS /boot/config-$(uname -r) # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set root@elgar:~> Try enabling it. Okay, it indeed helps. Just opened a PR for the Debian kernel: https://salsa.debian.org/kernel-team/linux/merge_requests/171 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Kernel 5.3.0 stuck during boot on Amiga
On Sep 18 2019, John Paul Adrian Glaubitz wrote: > On 9/18/19 6:23 PM, Andreas Schwab wrote: >> On Sep 18 2019, John Paul Adrian Glaubitz >> wrote: >> >>> [0.59] calling dh_init+0x0/0x10 @ 1 >>> [1.28] random: fast init done >>> [ 66.88] random: crng init done >>> [ 456.91] initcall dh_init+0x0/0x10 returned 0 after 445625000 usecs >> >> Is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS enabled? > > No: > > root@elgar:~> grep CONFIG_CRYPTO_MANAGER_DISABLE_TESTS /boot/config-$(uname > -r) > # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set > root@elgar:~> Try enabling it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Kernel 5.3.0 stuck during boot on Amiga
On 9/18/19 6:23 PM, Andreas Schwab wrote: On Sep 18 2019, John Paul Adrian Glaubitz wrote: [0.59] calling dh_init+0x0/0x10 @ 1 [1.28] random: fast init done [ 66.88] random: crng init done [ 456.91] initcall dh_init+0x0/0x10 returned 0 after 445625000 usecs Is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS enabled? No: root@elgar:~> grep CONFIG_CRYPTO_MANAGER_DISABLE_TESTS /boot/config-$(uname -r) # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set root@elgar:~> Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Kernel 5.3.0 stuck during boot on Amiga
On Sep 18 2019, John Paul Adrian Glaubitz wrote: > [0.59] calling dh_init+0x0/0x10 @ 1 > [1.28] random: fast init done > [ 66.88] random: crng init done > [ 456.91] initcall dh_init+0x0/0x10 returned 0 after 445625000 usecs Is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS enabled? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Kernel 5.3.0 stuck during boot on Amiga
Hi Adrian,
On Wed, Sep 18, 2019 at 3:57 PM John Paul Adrian Glaubitz
wrote:
> On 9/18/19 3:48 PM, Geert Uytterhoeven wrote:
> >> Diffie-Hellman doing some heavy crypto lifting on a poor m68k CPU?
> >>
> >> Disable CONFIG_CRYPTO_DH?
> >
> > See also https://lists.debian.org/debian-68k/2019/04/msg00033.html
> >
> > CRYPTO_DH is selected by CRYPTO_DEV_QAT and KEY_DH_OPERATIONS.
> > The latter is bool, forcing CRYPTO_DH builtin.
> >
> > If KEY_DH_OPERATIONS needs to be enabled in a Debian kernel, perhaps
> > it can be made tristate?
> It was enabled in [1] as it's required for certain WiFi drivers [2].
>
> So, should it be fixed as you suggest or should we selectively disable it on
> m68k?
Disabling it on m68k could be a first step (any WiFi drivers supported
on m68k yet?).
Making it tristate is non-trivial, as there are some interdependencies:
security/keys/Makefile:compat-obj-$(CONFIG_KEY_DH_OPERATIONS) += compat_dh.o
security/keys/Makefile:obj-$(CONFIG_KEY_DH_OPERATIONS) += dh.o
security/keys/internal.h:#ifdef CONFIG_KEY_DH_OPERATIONS
security/keys/keyctl.c:
(IS_ENABLED(CONFIG_KEY_DH_OPERATIONS)? KEYCTL_CAPS0_DIFFIE_HELLMAN
: 0) |
> > [1]
> > https://salsa.debian.org/kernel-team/linux/commit/88f44cb9eb34098138c79bdab5fae434492866d1
> > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911998
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Kernel 5.3.0 stuck during boot on Amiga
Hi! On 9/18/19 3:48 PM, Geert Uytterhoeven wrote: Diffie-Hellman doing some heavy crypto lifting on a poor m68k CPU? Disable CONFIG_CRYPTO_DH? See also https://lists.debian.org/debian-68k/2019/04/msg00033.html CRYPTO_DH is selected by CRYPTO_DEV_QAT and KEY_DH_OPERATIONS. The latter is bool, forcing CRYPTO_DH builtin. If KEY_DH_OPERATIONS needs to be enabled in a Debian kernel, perhaps it can be made tristate? It was enabled in [1] as it's required for certain WiFi drivers [2]. So, should it be fixed as you suggest or should we selectively disable it on m68k? Adrian [1] https://salsa.debian.org/kernel-team/linux/commit/88f44cb9eb34098138c79bdab5fae434492866d1 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911998 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Kernel 5.3.0 stuck during boot on Amiga
On Wed, Sep 18, 2019 at 3:41 PM Geert Uytterhoeven wrote:
> On Wed, Sep 18, 2019 at 3:36 PM John Paul Adrian Glaubitz
> wrote:
> > On 9/12/19 11:34 PM, Michael Schmitz wrote:
> > > try adding 'initcall_debug' to the kernel command line.
> > Attached the dmesg log with initcall_debug enabled. The delay was still
> > there
> > but no kernel OOPS.
>
> > [0.59] calling dh_init+0x0/0x10 @ 1
> > [1.28] random: fast init done
> > [ 66.88] random: crng init done
> > [ 456.91] initcall dh_init+0x0/0x10 returned 0 after 445625000 usecs
>
> Diffie-Hellman doing some heavy crypto lifting on a poor m68k CPU?
>
> Disable CONFIG_CRYPTO_DH?
See also https://lists.debian.org/debian-68k/2019/04/msg00033.html
CRYPTO_DH is selected by CRYPTO_DEV_QAT and KEY_DH_OPERATIONS.
The latter is bool, forcing CRYPTO_DH builtin.
If KEY_DH_OPERATIONS needs to be enabled in a Debian kernel, perhaps
it can be made tristate?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Kernel 5.3.0 stuck during boot on Amiga
Hi Adrian,
On Wed, Sep 18, 2019 at 3:36 PM John Paul Adrian Glaubitz
wrote:
> On 9/12/19 11:34 PM, Michael Schmitz wrote:
> > try adding 'initcall_debug' to the kernel command line.
> Attached the dmesg log with initcall_debug enabled. The delay was still there
> but no kernel OOPS.
> [0.59] calling dh_init+0x0/0x10 @ 1
> [1.28] random: fast init done
> [ 66.88] random: crng init done
> [ 456.91] initcall dh_init+0x0/0x10 returned 0 after 445625000 usecs
Diffie-Hellman doing some heavy crypto lifting on a poor m68k CPU?
Disable CONFIG_CRYPTO_DH?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Kernel 5.3.0 stuck during boot on Amiga
Hi Michael! On 9/12/19 11:34 PM, Michael Schmitz wrote: try adding 'initcall_debug' to the kernel command line. Attached the dmesg log with initcall_debug enabled. The delay was still there but no kernel OOPS. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 [0.00] Linux version 5.3.0-rc5-m68k (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-21)) #1 Debian 5.3~rc5-1~exp2 (2019-08-25) [0.00] Enabling workaround for errata I14 [0.00] Amiga hardware found: [A4000] VIDEO BLITTER AUDIO FLOPPY A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA LISA ALICE_PAL ZORRO3 [0.00] On node 0 totalpages: 30720 [0.00] DMA zone: 300 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 30720 pages, LIFO batch:7 [0.00] initrd: 06c226ca - 0780 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 30420 [0.00] Kernel command line: root=UUID=eadaf41d-6457-4e5b-b8cc-dbe3dc1c6b6d console=tty0 console=ttyS0,9600n8 modprobe.blacklist=amiflop,gayle initcall_debug [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [0.00] Sorting __ex_table... [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 104552K/122880K available (3043K kernel code, 394K rwdata, 1084K rodata, 160K init, 203K bss, 18328K reserved, 0K cma-reserved) [0.00] random: get_random_u32 called from __kmem_cache_create+0x2c/0x460 with crng_init=0 [0.00] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8 [0.00] NR_IRQS: 200 [0.00] clocksource: ciab: mask: 0x max_cycles: 0x, max_idle_ns: 2694272661900 ns [0.00] Console: colour dummy device 80x25 [0.00] printk: console [tty0] enabled [0.17] printk: console [ttyS0] enabled [0.18] Calibrating delay loop... 98.20 BogoMIPS (lpj=491008) [0.28] pid_max: default: 32768 minimum: 301 [0.30] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.31] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.36] calling spawn_ksoftirqd+0x0/0x46 @ 1 [0.36] initcall spawn_ksoftirqd+0x0/0x46 returned 0 after 0 usecs [0.36] calling dynamic_debug_init+0x0/0x20c @ 1 [0.37] initcall dynamic_debug_init+0x0/0x20c returned 0 after 9765 usecs [0.37] calling initialize_ptr_random+0x0/0xae @ 1 [0.37] initcall initialize_ptr_random+0x0/0xae returned 0 after 0 usecs [0.38] devtmpfs: initialized [0.40] calling ipc_ns_init+0x0/0x12 @ 1 [0.40] initcall ipc_ns_init+0x0/0x12 returned 0 after 0 usecs [0.40] calling init_mmap_min_addr+0x0/0xe @ 1 [0.40] initcall init_mmap_min_addr+0x0/0xe returned 0 after 0 usecs [0.40] calling net_ns_init+0x0/0x100 @ 1 [0.41] initcall net_ns_init+0x0/0x100 returned 0 after 9765 usecs [0.41] calling wq_sysfs_init+0x0/0x2a @ 1 [0.41] initcall wq_sysfs_init+0x0/0x2a returned 0 after 0 usecs [0.41] calling ksysfs_init+0x0/0x8e @ 1 [0.41] initcall ksysfs_init+0x0/0x8e returned 0 after 0 usecs [0.41] calling rcu_set_runtime_mode+0x0/0xc @ 1 [0.41] initcall rcu_set_runtime_mode+0x0/0xc returned 0 after 0 usecs [0.41] calling init_jiffies_clocksource+0x0/0x18 @ 1 [0.41] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.42] initcall init_jiffies_clocksource+0x0/0x18 returned 0 after 9765 usecs [0.42] calling futex_init+0x0/0x6e @ 1 [0.42] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [0.43] initcall futex_init+0x0/0x6e returned 0 after 9765 usecs [0.43] calling cgroup_wq_init+0x0/0x3a @ 1 [0.43] initcall cgroup_wq_init+0x0/0x3a returned 0 after 0 usecs [0.43] calling cgroup1_wq_init+0x0/0x3a @ 1 [0.43] initcall cgroup1_wq_init+0x0/0x3a returned 0 after 0 usecs [0.43] calling init_zero_pfn+0x0/0x8c @ 1 [0.43] initcall init_zero_pfn+0x0/0x8c returned 0 after 0 usecs [0.43] calling init_per_zone_wmark_min+0x0/0x6e @ 1 [0.43] initcall init_per_zone_wmark_min+0x0/0x6e returned 0 after 0 usecs [0.43] calling fsnotify_init+0x0/0x48 @ 1 [0.44] initcall fsnotify_init+0x0/0x48 returned 0 after 9765 usecs [0.44] calling filelock_init+0x0/0x50 @ 1 [0.44] initcall filelock_init+0x0/0x50 returned 0 after 0 usecs [0.44] calling
Re: Kernel 5.3.0 stuck during boot on Amiga
Hi Adrian, try adding 'initcall_debug' to the kernel command line. Cheers, Michael On 11/09/19 10:39 PM, John Paul Adrian Glaubitz wrote: On 9/11/19 12:13 PM, John Paul Adrian Glaubitz wrote: On 9/11/19 12:07 PM, John Paul Adrian Glaubitz wrote: I just tried booting kernel 5.3.0 (as well as 5.2.0) on my Amiga 4000 and it gets stuck rather early. The heartbeat LED is still pumping though. Okay, it proceeded now but produced this backtrace: And I cannot use the serial console for entering any text. After pressing multiple times, I got this: [ 2084.34] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper:0] [ 2084.34] Modules linked in: evdev mac_hid parport_amiga parport amimouse sg dmasound_paula dmasound_core soundcore 8390 loop ip_tables x_tables sha1_generic hmac ipva [ 2084.34] Format 00 Vector: 0078 PC: 2a86 Status: 2504 Not tainted [ 2084.34] ORIG_D0: D0: A2: 0040f31c A1: 0041f9a8 [ 2084.34] A0: 0040c000 D5: 08024018 D4: 000a [ 2084.34] D3: 0022 D2: D1: 0040c000 Adrian
Re: Kernel 5.3.0 stuck during boot on Amiga
On 9/11/19 12:13 PM, John Paul Adrian Glaubitz wrote: On 9/11/19 12:07 PM, John Paul Adrian Glaubitz wrote: I just tried booting kernel 5.3.0 (as well as 5.2.0) on my Amiga 4000 and it gets stuck rather early. The heartbeat LED is still pumping though. Okay, it proceeded now but produced this backtrace: And I cannot use the serial console for entering any text. After pressing multiple times, I got this: [ 2084.34] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper:0] [ 2084.34] Modules linked in: evdev mac_hid parport_amiga parport amimouse sg dmasound_paula dmasound_core soundcore 8390 loop ip_tables x_tables sha1_generic hmac ipva [ 2084.34] Format 00 Vector: 0078 PC: 2a86 Status: 2504Not tainted [ 2084.34] ORIG_D0: D0: A2: 0040f31c A1: 0041f9a8 [ 2084.34] A0: 0040c000 D5: 08024018 D4: 000a [ 2084.34] D3: 0022 D2: D1: 0040c000 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Kernel 5.3.0 stuck during boot on Amiga
On 9/11/19 12:07 PM, John Paul Adrian Glaubitz wrote: I just tried booting kernel 5.3.0 (as well as 5.2.0) on my Amiga 4000 and it gets stuck rather early. The heartbeat LED is still pumping though. Okay, it proceeded now but produced this backtrace: [ 484.30] irq 19: nobody cared (try booting with the "irqpoll" option) [ 484.31] CPU: 0 PID: 1 Comm: swapper Not tainted 5.3.0-rc5-m68k #1 Debian 5.3~rc5-1~exp2 [ 484.32] Stack from 0682dc78: [ 484.32] 0682dc78 003c0841 00056130 00418674 00437c30 00056076 00418674 [ 484.32] 00200140 000a 00418674 00437c30 004150b0 [ 484.32] 00054070 00418674 06820810 00418674 004186a8 0005409e [ 484.32] 00418674 00418674 000565d8 00418674 00418674 000539e4 00418674 7a5c [ 484.32] 0013 0682dd9c 000539e4 00417e5c 2bd4 0005 0002 2ab0 [ 484.32] 0005 0682dd20 0682c000 0002 00200140 000a 0682c000 [ 484.34] Call Trace: [<00056130>] __report_bad_irq+0x32/0x96 [ 484.35] [<00056076>] note_interrupt+0x15e/0x1cc [ 484.36] [<00200140>] scsi_send_eh_cmnd+0x1f8/0x350 [ 484.37] [<00054070>] handle_irq_event_percpu+0x42/0x52 [ 484.38] [<0005409e>] handle_irq_event+0x1e/0x30 [ 484.39] [<000565d8>] handle_simple_irq+0x54/0x58 [ 484.40] [<000539e4>] generic_handle_irq+0x18/0x22 [ 484.41] [<7a5c>] ami_int5+0x20/0x42 [ 484.42] [<000539e4>] generic_handle_irq+0x18/0x22 [ 484.43] [<2bd4>] do_IRQ+0x20/0x32 [ 484.44] [<2ab0>] auto_irqhandler_fixup+0x4/0xc [ 484.45] [<00200140>] scsi_send_eh_cmnd+0x1f8/0x350 [ 484.46] [<001e2014>] uart_parse_options+0x4/0x62 [ 484.47] [<0002f46e>] irq_exit+0x36/0x44 [ 484.48] [<474c>] do_notify_resume+0x116/0x18e [ 484.49] [<2bda>] do_IRQ+0x26/0x32 [ 484.50] [<2ab0>] auto_irqhandler_fixup+0x4/0xc [ 484.51] [<001e2014>] uart_parse_options+0x4/0x62 [ 484.52] [<001e7b00>] ser_rx_int+0x0/0x14a [ 484.53] [<0005524a>] request_threaded_irq+0x92/0x124 [ 484.54] [<000551b8>] request_threaded_irq+0x0/0x124 [ 484.55] [<004846f2>] amiga_serial_probe+0x190/0x21a [ 484.56] [<001e7b00>] ser_rx_int+0x0/0x14a [ 484.57] [<001f21e6>] platform_drv_probe+0x1a/0x46 [ 484.59] [<001f09dc>] really_probe+0x208/0x306 [ 484.60] [<0004000c>] parse_args+0x0/0x2c4 [ 484.61] [<001f0eba>] device_driver_attach+0x30/0x50 [ 484.62] [<001f0ff4>] __driver_attach+0x11a/0x11e [ 484.63] [<001eedfe>] next_device+0x0/0x18 [ 484.64] [<001eee08>] next_device+0xa/0x18 [ 484.65] [<001eee72>] bus_for_each_dev+0x5c/0x82 [ 484.66] [<001f035a>] driver_attach+0x16/0x1c [ 484.67] [<001f0eda>] __driver_attach+0x0/0x11e [ 484.68] [<001efe92>] bus_add_driver+0x17c/0x1ac [ 484.69] [<001f14f6>] driver_register+0x94/0xcc [ 484.70] [<001f25ba>] __platform_driver_probe+0x56/0x92 [ 484.71] [<0048454a>] amiga_serial_driver_init+0x0/0x18 [ 484.72] [<0048455c>] amiga_serial_driver_init+0x12/0x18 [ 484.73] [<00484562>] amiga_serial_probe+0x0/0x21a [ 484.74] [<20f0>] do_one_initcall+0x5a/0x184 [ 484.75] [<0004000c>] parse_args+0x0/0x2c4 [ 484.76] [<2096>] do_one_initcall+0x0/0x184 [ 484.77] [<002ef3d2>] strcpy+0x0/0x1c [ 484.78] [<00060006>] ntp_clear+0x22/0x5c [ 484.79] [<00471090>] kernel_init_freeable+0xe4/0x18c [ 484.80] [<002ef3d2>] strcpy+0x0/0x1c [ 484.81] [<0047112c>] kernel_init_freeable+0x180/0x18c [ 484.82] [<0048454a>] amiga_serial_driver_init+0x0/0x18 [ 484.83] [<002f5192>] kernel_init+0x0/0xd2 [ 484.84] [<002f519a>] kernel_init+0x8/0xd2 [ 484.85] [<002f5192>] kernel_init+0x0/0xd2 [ 484.86] [<2930>] ret_from_kernel_thread+0xc/0x14 [ 484.87] handlers: [ 484.88] [<19313236>] ser_rx_int [ 484.89] Disabling IRQ #19 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 2/2] drivers/ata: convert pata_falcon to arch platform device
Hi Michael,
On Tue, Jul 2, 2019 at 12:02 AM Michael Schmitz wrote:
> The Atari platform device setup now provides a platform device
> for the Falcon IDE interface. Use this in place of the simple platform
> device set up in the old pata_falcon probe code.
>
> Signed-off-by: Michael Schmitz
Thanks for your patch!
> --- a/drivers/ata/pata_falcon.c
> +++ b/drivers/ata/pata_falcon.c
> @@ -120,23 +120,21 @@ static int pata_falcon_set_mode(struct ata_link *link,
> .set_mode = pata_falcon_set_mode,
> };
>
> -static int pata_falcon_init_one(void)
> +static int __init pata_falcon_init_one(struct platform_device *pdev)
> {
> + struct resource *res;
> struct ata_host *host;
> struct ata_port *ap;
> - struct platform_device *pdev;
> void __iomem *base;
>
> - if (!MACH_IS_ATARI || !ATARIHW_PRESENT(IDE))
> - return -ENODEV;
> -
> - pr_info(DRV_NAME ": Atari Falcon PATA controller\n");
> + dev_info(>dev, ": Atari Falcon PATA controller\n");
>
> - pdev = platform_device_register_simple(DRV_NAME, 0, NULL, 0);
> - if (IS_ERR(pdev))
> - return PTR_ERR(pdev);
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENODEV;
>
> - if (!devm_request_mem_region(>dev, ATA_HD_BASE, 0x40,
> DRV_NAME)) {
ATA_HD_BASE is now unused, and can be removed.
> + if (!devm_request_mem_region(>dev, res->start,
> +resource_size(res), DRV_NAME)) {
> pr_err(DRV_NAME ": resources busy\n");
dev_err(>dev, "resources busy\n");
> return -EBUSY;
> }
> @@ -174,9 +172,26 @@ static int pata_falcon_init_one(void)
> return ata_host_activate(host, 0, NULL, 0, _falcon_sht);
> }
>
> -module_init(pata_falcon_init_one);
> +static int __exit pata_falcon_remove_one(struct platform_device *pdev)
> +{
> + struct ata_host *host = platform_get_drvdata(pdev);
> +
> + ata_host_detach(host);
> +
> + return 0;
> +}
> +
> +static struct platform_driver pata_falcon_driver = {
> + .remove = __exit_p(pata_falcon_remove_one),
> + .driver = {
> + .name = "atari-falcon-ide",
> + },
> +};
> +
> +module_platform_driver_probe(pata_falcon_driver, pata_falcon_init_one);
This doesn't seem to work in the builtin case (e.g. atari_defconfig with
ide replaced by ata): no hard drives are detected.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] m68k/atari: add platform device for Falcon IDE port
Hi Michael,
On Tue, Jul 2, 2019 at 12:02 AM Michael Schmitz wrote:
> Autoloading of Falcon IDE driver modules requires converting
> these drivers to platform drivers.
>
> Add platform device for Falcon IDE interface in Atari platform
> setup code in preparation for this.
>
> Signed-off-by: Michael Schmitz
>
> --
>
> Changes from RFC
>
> - fix region size (spotted by Szymon Bieganski )
> - define IDE interface address in atari/config.c, create platform device
> always (suggested by Geert Uytterhoeven )
Thanks for the update!
Looks good to me. However, with just this patch applied, pata_falcon
fails with:
pata_falcon: Atari Falcon PATA controller
pata_falcon: resources busy
To avoid bisection issues, probably both patches should be combined into a
single patch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
IF YOU ARE INTERESTED REPLY BACK.
-- Greetings To You Friend, I Am Mr. Diouf Mouka From Burkina Faso I Have A Genuine Business Transaction Of 30million U.S Dollars To Do With You If You Are Interested Send To Me The Following Information Immediately. Your Full Name.. Your Occupation. Your Age Your Marital Status. Your Phone Number. Your Country/Nationality. Best Regard, Diouf Mouka.
Singaporean Mr. Teo En Ming's Refugee Seeking Attempts
Subject: Singaporean Mr. Teo En Ming's Refugee Seeking Attempts In reverse chronological order: [1] Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday Photo #1: At the building of the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photo #2: Queue ticket at the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photo #3: Submission of documents/petition to the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photos #4 and #5: Acknowledgement of Receipt for the submission of documents/petition from the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 References: (a) Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday (Blogspot) Link: https://tdtemcerts.blogspot.sg/2019/08/petition-to-government-of-taiwan-for.html (b) Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday (Wordpress) Link: https://tdtemcerts.wordpress.com/2019/08/23/petition-to-the-government-of-taiwan-for-refugee-status/ [2] Application for Refugee Status at the United Nations Refugee Agency, Bangkok, Thailand, 21st March 2017 Tuesday References: (a) [YOUTUBE] Vlog: The Road to Application for Refugee Status at UNHCR Bangkok Link: https://www.youtube.com/watch?v=utpuAa1eUNI YouTube video Published on March 22nd, 2017 -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
Re: [PATCH] m68k: coldfire: Include the GPIO driver header
Hi Geert, Linus,
On 21/8/19 10:50 pm, Geert Uytterhoeven wrote:
On Wed, Aug 21, 2019 at 2:22 PM Greg Ungerer wrote:
On 21/8/19 5:19 pm, Geert Uytterhoeven wrote:
CC Greg (coldfire)
Thanks Geert.
I am happy to take it via the m68knommu tree if you prefer?
Sounds most logical to me.
Thanks!
Pushed to the for-next branch of the m68knommu git tree.
Regards
Greg
On Wed, Aug 21, 2019 at 9:09 AM Linus Walleij wrote:
The Coldfire GPIO driver needs to explicitly incldue the
GPIO driver header since it is providing a driver.
Cc: Geert Uytterhoeven
Signed-off-by: Linus Walleij
---
Geert can you pick this up for m68k?
---
arch/m68k/coldfire/gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/coldfire/gpio.c b/arch/m68k/coldfire/gpio.c
index a83898426127..ca26de257871 100644
--- a/arch/m68k/coldfire/gpio.c
+++ b/arch/m68k/coldfire/gpio.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
Gr{oetje,eeting}s,
Geert
Re: [PATCH] m68k: coldfire: Include the GPIO driver header
Hi Greg,
On Wed, Aug 21, 2019 at 2:22 PM Greg Ungerer wrote:
> On 21/8/19 5:19 pm, Geert Uytterhoeven wrote:
> > CC Greg (coldfire)
>
> Thanks Geert.
> I am happy to take it via the m68knommu tree if you prefer?
Sounds most logical to me.
Thanks!
> > On Wed, Aug 21, 2019 at 9:09 AM Linus Walleij
> > wrote:
> >> The Coldfire GPIO driver needs to explicitly incldue the
> >> GPIO driver header since it is providing a driver.
> >>
> >> Cc: Geert Uytterhoeven
> >> Signed-off-by: Linus Walleij
> >> ---
> >> Geert can you pick this up for m68k?
> >> ---
> >> arch/m68k/coldfire/gpio.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/m68k/coldfire/gpio.c b/arch/m68k/coldfire/gpio.c
> >> index a83898426127..ca26de257871 100644
> >> --- a/arch/m68k/coldfire/gpio.c
> >> +++ b/arch/m68k/coldfire/gpio.c
> >> @@ -9,6 +9,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >> #include
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] m68k: coldfire: Include the GPIO driver header
On 21/8/19 5:19 pm, Geert Uytterhoeven wrote: CC Greg (coldfire) Thanks Geert. I am happy to take it via the m68knommu tree if you prefer? Regards Greg On Wed, Aug 21, 2019 at 9:09 AM Linus Walleij wrote: The Coldfire GPIO driver needs to explicitly incldue the GPIO driver header since it is providing a driver. Cc: Geert Uytterhoeven Signed-off-by: Linus Walleij --- Geert can you pick this up for m68k? --- arch/m68k/coldfire/gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/m68k/coldfire/gpio.c b/arch/m68k/coldfire/gpio.c index a83898426127..ca26de257871 100644 --- a/arch/m68k/coldfire/gpio.c +++ b/arch/m68k/coldfire/gpio.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include -- 2.21.0
Re: [PATCH] m68k: coldfire: Include the GPIO driver header
CC Greg (coldfire) On Wed, Aug 21, 2019 at 9:09 AM Linus Walleij wrote: > The Coldfire GPIO driver needs to explicitly incldue the > GPIO driver header since it is providing a driver. > > Cc: Geert Uytterhoeven > Signed-off-by: Linus Walleij > --- > Geert can you pick this up for m68k? > --- > arch/m68k/coldfire/gpio.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/m68k/coldfire/gpio.c b/arch/m68k/coldfire/gpio.c > index a83898426127..ca26de257871 100644 > --- a/arch/m68k/coldfire/gpio.c > +++ b/arch/m68k/coldfire/gpio.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > #include > #include > -- > 2.21.0
Your contact request
Thank you for contacting us! We will be in touch.
Re: [PATCH v2 1/3] mmc: add Coldfire esdhc support
On 6/07/19 2:20 PM, Angelo Dureghello wrote: > Hi Adrian, > > On Tue, Jul 02, 2019 at 12:10:54PM +0300, Adrian Hunter wrote: >> On 20/06/19 1:22 AM, Angelo Dureghello wrote: >>> Hi Christoph, >>> >>> On Sun, Jun 16, 2019 at 11:58:07PM -0700, Christoph Hellwig wrote: On Sun, Jun 16, 2019 at 10:48:21PM +0200, Angelo Dureghello wrote: > This driver has been developed as a separate module starting > from the similar sdhci-esdhc-fls.c. > Separation has been mainly driven from change in endianness. Can't we have a way to define the endianess at build or even runtime? We have plenty of that elsewhere in the kernel. >>> >>> well, the base sdhci layer wants to access byte-size fields of the >>> esdhc controller registers. >>> But this same Freescale esdhc controller may be found in 2 >>> flavors, big-endian or little-endian organized. >>> So in this driver i am actually correcting byte-addresses to >>> access the wanted byte-field in the big-endian hw controller. >>> >>> So this is a bit different from a be-le endian swap of a >>> long or a short that the kernel is organized to do.. >> >> Did you consider just using different sdhci_ops so that you could support >> different sdhci I/O accessors? > > Initially i tried to modify the IMX/Vybrid (arm) driver. But was stopped from > several points, trying to remember now, > > - the I/O accessors was a const struct, but this of course is not a big > issue, > - here and there bitfields and positions of the ColdFire controller > registers, compared to the arm versions, are different, so controller hw > is not exactly the same, > - on ColdFire controller and some behaviors and errata are different, > - dma endiannes not hw-configurable, > - ColdFire has max clock limitations, a bit different clock init. > > Finally, since there is already a common library (shdci.c) i decided to go > as a separate driver, instead of filling the driver of "if (coldfire)" also > mainly for the following reasons: > > 1) separated ColdFire driver has a quite small amount of code, simple to > understand. > 2) having drivers used by multiple architectures, it add risks, each time > i perform a change, i can test it only on ColdFire, and can break > the driver for the other architectures (i see this not rarely happening for > multiple-arch used drivers). > > So let me know if the way chosen can be ok. Otherwise i will roll back > trying to modify the iMX/Vybrid driver, likely adding a lot of "if (coldfire)" > complicating it quite a lot. "if (coldfire)" is not very nice, and there doesn't seem to be that much common code, so let's stick with a separate driver, but please change the commit message in consideration of this discussion.
PLEASE CONFIRM PURCHASE ORDER
Could you please confirm if your recieved our purchase order last week. If no please confirm let me resend it to you. NARESH KUMAR Executive Purchase Saiapextrading Ltd Dubai, KSA. (T/F): +96-2667-264 777 / 778 (Mo): +96 94284 02803 Website - http://www.saiapexgeneraltrading.com
Re: [pinctrl:devel 16/46] drivers/pinctrl/bcm/pinctrl-bcm2835.c:995:10: error: incompatible types when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
Hi Michael,
On Sun, Aug 11, 2019 at 11:13 PM Michael Schmitz wrote:
> Leaves the matter of who prepares a patch to atarihw.h and users of that
> definition ...
At your service...
> Am 12.08.19 um 09:01 schrieb Stefan Wahren:
> > Am 07.08.19 um 00:41 schrieb Michael Schmitz:
> >> could be renamed shifter_st, I suppose. Only used in
> >> arch/m68k/atari/config.c and drivers/video/fbdev/atafb.c.
> > looks like you've come to a solution. Is there any action required from
> > my side?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [pinctrl:devel 16/46] drivers/pinctrl/bcm/pinctrl-bcm2835.c:995:10: error: incompatible types when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
Stefan, considering that such a clash could happen again, it might be prudent to use a less generic name in your driver as well? Leaves the matter of who prepares a patch to atarihw.h and users of that definition ... Cheers, Michael Am 12.08.19 um 09:01 schrieb Stefan Wahren: > Hi, > > Am 07.08.19 um 00:41 schrieb Michael Schmitz: >> Hi Geert, >> >> could be renamed shifter_st, I suppose. Only used in >> arch/m68k/atari/config.c and drivers/video/fbdev/atafb.c. > looks like you've come to a solution. Is there any action required from > my side? > > Regards > Stefan > >> Cheers, >> >> Michael
Re: [pinctrl:devel 16/46] drivers/pinctrl/bcm/pinctrl-bcm2835.c:995:10: error: incompatible types when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
Hi, Am 07.08.19 um 00:41 schrieb Michael Schmitz: > Hi Geert, > > could be renamed shifter_st, I suppose. Only used in > arch/m68k/atari/config.c and drivers/video/fbdev/atafb.c. looks like you've come to a solution. Is there any action required from my side? Regards Stefan > > Cheers, > > Michael
Re: [pinctrl:devel 16/46] drivers/pinctrl/bcm/pinctrl-bcm2835.c:995:10: error: incompatible types when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
Hi Michael,
On Wed, Aug 7, 2019 at 12:41 AM Michael Schmitz wrote:
> could be renamed shifter_st, I suppose. Only used in
> arch/m68k/atari/config.c and drivers/video/fbdev/atafb.c.
Yeah, exactly my thought.
> On 6/08/19 7:33 PM, Geert Uytterhoeven wrote:
> > CC linux-m68k (shifter too generic a name?)
> >
> > On Tue, Aug 6, 2019 at 5:00 AM kbuild test robot wrote:
> >> tree:
> >> https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
> >> devel
> >> head: d55b7fdd58ac12e76ef65979af4a13b9c15fc00d
> >> commit: e38a9a437fb93ddafab5030165e4c6a3a5021669 [16/46] pinctrl: bcm2835:
> >> Add support for BCM2711 pull-up functionality
> >> config: m68k-allmodconfig (attached as .config)
> >> compiler: m68k-linux-gcc (GCC) 7.4.0
> >> reproduce:
> >> wget
> >> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> >> -O ~/bin/make.cross
> >> chmod +x ~/bin/make.cross
> >> git checkout e38a9a437fb93ddafab5030165e4c6a3a5021669
> >> # save the attached .config to linux build tree
> >> GCC_VERSION=7.4.0 make.cross ARCH=m68k
> >>
> >> If you fix the issue, kindly add following tag
> >> Reported-by: kbuild test robot
> >>
> >> All error/warnings (new ones prefixed by >>):
> >>
> >> In file included from arch/m68k/include/asm/io_mm.h:32:0,
> >> from arch/m68k/include/asm/io.h:8,
> >> from include/linux/io.h:13,
> >> from include/linux/irq.h:20,
> >> from include/linux/gpio/driver.h:7,
> >> from drivers/pinctrl/bcm/pinctrl-bcm2835.c:17:
> >> drivers/pinctrl/bcm/pinctrl-bcm2835.c: In function
> >> 'bcm2711_pull_config_set':
> arch/m68k/include/asm/atarihw.h:190:22: error: expected identifier or
> '(' before 'volatile'
> >> # define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
> >> ^
> drivers/pinctrl/bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
> 'shifter'
> >> u32 shifter;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
PARTNERSHIP REQUEST,
Dear Friend, I need you to please let me know if there are fast growing investments in your country in which i can invest money in. I have access to a huge amount of money, which i want to invest in your country, i want to know if you can be an agent/partner to me and i will give you a commission of 30% only If you agree to assist me, i will like to know if the commission is ok for you, also i would love to know more about you too. Get Back to me without delay if you are interested Yours Faithfully Simon Beron.
Re: [pinctrl:devel 16/46] drivers/pinctrl/bcm/pinctrl-bcm2835.c:995:10: error: incompatible types when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
Hi Geert,
could be renamed shifter_st, I suppose. Only used in
arch/m68k/atari/config.c and drivers/video/fbdev/atafb.c.
Cheers,
Michael
On 6/08/19 7:33 PM, Geert Uytterhoeven wrote:
CC linux-m68k (shifter too generic a name?)
On Tue, Aug 6, 2019 at 5:00 AM kbuild test robot wrote:
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
devel
head: d55b7fdd58ac12e76ef65979af4a13b9c15fc00d
commit: e38a9a437fb93ddafab5030165e4c6a3a5021669 [16/46] pinctrl: bcm2835: Add
support for BCM2711 pull-up functionality
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e38a9a437fb93ddafab5030165e4c6a3a5021669
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=m68k
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
In file included from arch/m68k/include/asm/io_mm.h:32:0,
from arch/m68k/include/asm/io.h:8,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from include/linux/gpio/driver.h:7,
from drivers/pinctrl/bcm/pinctrl-bcm2835.c:17:
drivers/pinctrl/bcm/pinctrl-bcm2835.c: In function
'bcm2711_pull_config_set':
arch/m68k/include/asm/atarihw.h:190:22: error: expected identifier or '('
before 'volatile'
# define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
^
drivers/pinctrl/bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
'shifter'
u32 shifter;
^~~
arch/m68k/include/asm/atarihw.h:172:17: error: expected ')' before '(' token
#define SHF_BAS (0x8200)
^
arch/m68k/include/asm/atarihw.h:190:48: note: in expansion of macro 'SHF_BAS'
# define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
^~~
drivers/pinctrl/bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
'shifter'
u32 shifter;
^~~
drivers/pinctrl/bcm/pinctrl-bcm2835.c:995:10: error: incompatible types when
assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
shifter = PUD_2711_REG_SHIFT(pin);
^
drivers/pinctrl/bcm/pinctrl-bcm2835.c:998:27: error: invalid operands to binary
<< (have 'int' and 'volatile struct SHIFTER')
value &= ~(PUD_2711_MASK << shifter);
^~
drivers/pinctrl/bcm/pinctrl-bcm2835.c:999:16: error: invalid operands to binary
<< (have 'unsigned int' and 'volatile struct SHIFTER')
value |= (arg << shifter);
^~
--
In file included from arch/m68k/include/asm/io_mm.h:32:0,
from arch/m68k/include/asm/io.h:8,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from include/linux/gpio/driver.h:7,
from drivers/pinctrl//bcm/pinctrl-bcm2835.c:17:
drivers/pinctrl//bcm/pinctrl-bcm2835.c: In function
'bcm2711_pull_config_set':
arch/m68k/include/asm/atarihw.h:190:22: error: expected identifier or '('
before 'volatile'
# define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
^
drivers/pinctrl//bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
'shifter'
u32 shifter;
^~~
arch/m68k/include/asm/atarihw.h:172:17: error: expected ')' before '(' token
#define SHF_BAS (0x8200)
^
arch/m68k/include/asm/atarihw.h:190:48: note: in expansion of macro 'SHF_BAS'
# define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
^~~
drivers/pinctrl//bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
'shifter'
u32 shifter;
^~~
drivers/pinctrl//bcm/pinctrl-bcm2835.c:995:10: error: incompatible types
when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
shifter = PUD_2711_REG_SHIFT(pin);
^
drivers/pinctrl//bcm/pinctrl-bcm2835.c:998:27: error: invalid operands to binary
<< (have 'int' and 'volatile struct SHIFTER')
value &= ~(PUD_2711_MASK << shifter);
^~
drivers/pinctrl//bcm/pinctrl-bcm2835.c:999:16: error: invalid operands to binary
<< (have 'unsigned int' and 'volatile struct SHIFTER')
value |= (arg << shifter);
^~
vim +995 drivers/pinctrl/bcm/pinctrl-bcm2835.c
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [pinctrl:devel 16/46] drivers/pinctrl/bcm/pinctrl-bcm2835.c:995:10: error: incompatible types when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
CC linux-m68k (shifter too generic a name?)
On Tue, Aug 6, 2019 at 5:00 AM kbuild test robot wrote:
>
> tree:
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
> devel
> head: d55b7fdd58ac12e76ef65979af4a13b9c15fc00d
> commit: e38a9a437fb93ddafab5030165e4c6a3a5021669 [16/46] pinctrl: bcm2835:
> Add support for BCM2711 pull-up functionality
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 7.4.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout e38a9a437fb93ddafab5030165e4c6a3a5021669
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=m68k
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> All error/warnings (new ones prefixed by >>):
>
>In file included from arch/m68k/include/asm/io_mm.h:32:0,
> from arch/m68k/include/asm/io.h:8,
> from include/linux/io.h:13,
> from include/linux/irq.h:20,
> from include/linux/gpio/driver.h:7,
> from drivers/pinctrl/bcm/pinctrl-bcm2835.c:17:
>drivers/pinctrl/bcm/pinctrl-bcm2835.c: In function
> 'bcm2711_pull_config_set':
> >> arch/m68k/include/asm/atarihw.h:190:22: error: expected identifier or '('
> >> before 'volatile'
> # define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
> ^
> >> drivers/pinctrl/bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
> >> 'shifter'
> u32 shifter;
> ^~~
> >> arch/m68k/include/asm/atarihw.h:172:17: error: expected ')' before '('
> >> token
> #define SHF_BAS (0x8200)
> ^
> >> arch/m68k/include/asm/atarihw.h:190:48: note: in expansion of macro
> >> 'SHF_BAS'
> # define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
>^~~
> >> drivers/pinctrl/bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
> >> 'shifter'
> u32 shifter;
> ^~~
> >> drivers/pinctrl/bcm/pinctrl-bcm2835.c:995:10: error: incompatible types
> >> when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
> shifter = PUD_2711_REG_SHIFT(pin);
> ^
> >> drivers/pinctrl/bcm/pinctrl-bcm2835.c:998:27: error: invalid operands to
> >> binary << (have 'int' and 'volatile struct SHIFTER')
> value &= ~(PUD_2711_MASK << shifter);
> ^~
> >> drivers/pinctrl/bcm/pinctrl-bcm2835.c:999:16: error: invalid operands to
> >> binary << (have 'unsigned int' and 'volatile struct SHIFTER')
> value |= (arg << shifter);
>^~
> --
>In file included from arch/m68k/include/asm/io_mm.h:32:0,
> from arch/m68k/include/asm/io.h:8,
> from include/linux/io.h:13,
> from include/linux/irq.h:20,
> from include/linux/gpio/driver.h:7,
> from drivers/pinctrl//bcm/pinctrl-bcm2835.c:17:
>drivers/pinctrl//bcm/pinctrl-bcm2835.c: In function
> 'bcm2711_pull_config_set':
> >> arch/m68k/include/asm/atarihw.h:190:22: error: expected identifier or '('
> >> before 'volatile'
> # define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
> ^
>drivers/pinctrl//bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
> 'shifter'
> u32 shifter;
> ^~~
> >> arch/m68k/include/asm/atarihw.h:172:17: error: expected ')' before '('
> >> token
> #define SHF_BAS (0x8200)
> ^
> >> arch/m68k/include/asm/atarihw.h:190:48: note: in expansion of macro
> >> 'SHF_BAS'
> # define shifter ((*(volatile struct SHIFTER *)SHF_BAS))
>^~~
>drivers/pinctrl//bcm/pinctrl-bcm2835.c:990:6: note: in expansion of macro
> 'shifter'
> u32 shifter;
> ^~~
>drivers/pinctrl//bcm/pinctrl-bcm2835.c:995:10: error: incompatible types
> when assigning to type 'volatile struct SHIFTER' from type 'unsigned int'
> shifter = PUD_2711_REG_SHIFT(pin);
> ^
>drivers/pinctrl//bcm/pinctrl-bcm2835.c:998:27: error: invalid operands to
> binary << (have 'int' and 'volatile struct SHIFTER')
> value &= ~(PUD_2711_MASK << shifter);
> ^~
>drivers/pinctrl//bcm/pinctrl-bcm2835.c:999:16: error: invalid operands to
> binary << (have 'unsigned int' and 'volatile struct SHIFTER')
> value |= (arg << shifter);
>^~
>
> vim +995 drivers/pinctrl/bcm/pinctrl-bcm2835.c
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
Hi Finn,
On Wed, Jul 31, 2019 at 1:46 PM Finn Thain wrote:
> On Wed, 31 Jul 2019, Geert Uytterhoeven wrote:
> > On Wed, Jul 31, 2019 at 9:47 AM Finn Thain
> > wrote:
> > > It's annoying that we can't unconditionally include atarihw.h but I don't
> > > have a solution for that.
> >
> > The real issue is including , right?
>
> I take it you meant to write not .
Bummer, the Amiga-fanboy deep inside me never dies ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
On Thu, 1 Aug 2019, Michael Schmitz wrote: > >> > >> It's annoying that we can't unconditionally include atarihw.h but I > >> don't have a solution for that. > > The real issue is including , right? > > > > At first sight, the only reason for that is: > > > > #define atari_readb raw_inb > > #define atari_writeb raw_outb > > > > #define atari_inb_p raw_inb > > #define atari_outb_p raw_outb > > > > Note that the first definition is unused, and the other 3 have only a > > handful > > users. > > > > At second sight, the include can just be removed, an Atari > > kernel still builds fine... > > > What is used for raw_inb() and raw_outb() in that case? > > If it's still in_8() and out_8(), no harm done ... > The object files I looked at, pata_falcon.o and falconide.o, are unchanged. I think this relies on the fact that linux/io.h includes asm/io.h early on. The latter then includes asm/io_mm.h, which does this: #include #include #include #include #ifdef CONFIG_ATARI #include #endif -- > Cheers, > >Michael
LOANS !!!
Dial Direct Loan SA Consolidate your debts with Dial Direct Loan SA for your peace of mind at a fixed interest rate of 4.75%,personal and business loans are also welcome.For details file in your applications by sending an email to:dialdirectloan...@mail2consultant.com. Yours in Service, Susan Muller (Mrs.), Senior Consultant, Loan Application Team Dial Direct Loan SA Tel No: +27717231058
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
Hi Geert,
Am 31.07.19 um 20:20 schrieb Geert Uytterhoeven:
> Hi Finn,
>
> On Wed, Jul 31, 2019 at 9:47 AM Finn Thain wrote:
>> On Wed, 31 Jul 2019, Greg Ungerer wrote:
>>> No, not sufficient. You still get the following warnings after
>>> just moving that include of atarihw.h:
>>>
>>> CC arch/m68k/kernel/setup.o
>>> In file included from arch/m68k/kernel/setup_mm.c:48:0,
>>> from arch/m68k/kernel/setup.c:3:
>>> ./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data'
>>> declared inside parameter list
>>> extern void mac_irq_enable(struct irq_data *data);
>>>^
>>> ./arch/m68k/include/asm/macintosh.h:19:35: warning: its scope is only this
>>> definition or declaration, which is probably not what you want
>>> ./arch/m68k/include/asm/macintosh.h:20:36: warning: 'struct irq_data'
>>> declared inside parameter list
>>> extern void mac_irq_disable(struct irq_data *data);
>>>
>> The warning can be resolved with,
>>
>> diff --git a/arch/m68k/include/asm/macintosh.h
>> b/arch/m68k/include/asm/macintosh.h
>> index d9a08bed4b12..f653b60f2afc 100644
>> --- a/arch/m68k/include/asm/macintosh.h
>> +++ b/arch/m68k/include/asm/macintosh.h
>> @@ -4,6 +4,7 @@
>>
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> so that macintosh.h could be unconditionally included to avoid some
>> #ifdefs. That's just BTW. I don't object to your solution.
>>
>>> The MACH_IS_ATARI is not guaranteed to be compile time constant,
>>> depending on what target options you have configured.
>>>
>> Actually, MACH_IS_ATARI is a compile-time constant when CONFIG_ATARI=n.
>>
>> When I build that file with mac_defconfig and gcc 6.4, the C preprocessor
>> generates this:
>>
>>if ((0))
>> unknown = amiga_parse_bootinfo(record);
>>else if ((0))
>> unknown = atari_parse_bootinfo(record);
>>else if ((1))
>> unknown = mac_parse_bootinfo(record);
>>else if ((0))
>> unknown = q40_parse_bootinfo(record);
>>else if ((0))
>> unknown = bvme6000_parse_bootinfo(record);
>>else if ((0))
>> unknown = mvme16x_parse_bootinfo(record);
>>else if ((0))
>> unknown = mvme147_parse_bootinfo(record);
>>else if ((0))
>> unknown = hp300_parse_bootinfo(record);
>>else if ((0))
>> unknown = apollo_parse_bootinfo(record);
>>else
>> unknown = 1;
>>
>> We don't get that "implicit declaration" warning because the function
>> prototypes are all declared unconditionally at the top of the same file.
>>
>> Anyway, the warning we were discussing was this one:
>>
>> arch/m68k/kernel/setup_mm.c: In function 'm68k_nvram_get_size':
>> arch/m68k/kernel/setup_mm.c:605:10: error: implicit declaration of
>> function 'atari_nvram_get_size' [-Werror=implicit-function-declaration]
>>return atari_nvram_get_size();
>>
>> This warning is the reason why commit d3b41b6bb49e ("m68k: Dispatch
>> nvram_ops calls to Atari or Mac functions") unconditionally included
>> atarihw.h.
>>
>> It's annoying that we can't unconditionally include atarihw.h but I don't
>> have a solution for that.
> The real issue is including , right?
>
> At first sight, the only reason for that is:
>
> #define atari_readb raw_inb
> #define atari_writeb raw_outb
>
> #define atari_inb_p raw_inb
> #define atari_outb_p raw_outb
>
> Note that the first definition is unused, and the other 3 have only a handful
> users.
>
> At second sight, the include can just be removed, an Atari
> kernel still builds fine...
What is used for raw_inb() and raw_outb() in that case?
If it's still in_8() and out_8(), no harm done ...
Cheers,
Michael
>
> Would that fix the issue?
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
On Wed, 31 Jul 2019, Greg Ungerer wrote: > > > > Here's the patch I tested. > > > > diff --git a/arch/m68k/include/asm/atarihw.h > > b/arch/m68k/include/asm/atarihw.h > > index 533008262b69..ba1889c1a933 100644 > > --- a/arch/m68k/include/asm/atarihw.h > > +++ b/arch/m68k/include/asm/atarihw.h > > @@ -22,7 +22,6 @@ > > #include > > #include > > -#include > > #include > > extern u_long atari_mch_cookie; > > diff --git a/arch/m68k/include/asm/macintosh.h > > b/arch/m68k/include/asm/macintosh.h > > index d9a08bed4b12..f653b60f2afc 100644 > > --- a/arch/m68k/include/asm/macintosh.h > > +++ b/arch/m68k/include/asm/macintosh.h > > @@ -4,6 +4,7 @@ > > #include > > #include > > +#include > > #include > > > > I built 4 configurations - coldfire (mmu), atari, mac, atari + mac. > > > > It's hard to imagine that removing those extra #defines would be a problem > > given that doing so doesn't lead to compiler warnings or errors. The atari > > build booted up okay in aranym. > > Works for me too. I prefer this solution. > > Do you want to resend that patch with commit message and signed-off-by? > Sure, but I would like to understand this problem a bit better first. I wanted to be able to safely #include but this solution begs the question, why can't we safely #include ? $ git grep -w asm/raw_io.h arch/m68k/ arch/m68k/include/asm/atarihw.h:#include arch/m68k/include/asm/io_mm.h:#include arch/m68k/include/asm/nubus.h:#include arch/m68k/include/asm/q40_master.h:#include arch/m68k/include/asm/vga.h:#include arch/m68k/include/asm/zorro.h:#include $ It looks like asm/vga.h has exactly the same redefinition problem that asm/atarihw.h has. Apparently it never shows up due to #undef readb etc. My suspicion is that #undef directives are always unsafe, given the usual unpredictable ordering of #include directives. BTW, I see that asm/io_mm.h conditionally includes asm/atarihw.h, which suggests to me that unconditionally including asm/atarihw.h is not desirable for some reason (c.f. your original solution). -- > Regards > Greg > >
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
Hi Finn,
On 31/7/19 9:46 pm, Finn Thain wrote:
On Wed, 31 Jul 2019, Geert Uytterhoeven wrote:
On Wed, Jul 31, 2019 at 9:47 AM Finn Thain wrote:
On Wed, 31 Jul 2019, Greg Ungerer wrote:
No, not sufficient. You still get the following warnings after
just moving that include of atarihw.h:
CC arch/m68k/kernel/setup.o
In file included from arch/m68k/kernel/setup_mm.c:48:0,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data'
declared inside parameter list
extern void mac_irq_enable(struct irq_data *data);
^
./arch/m68k/include/asm/macintosh.h:19:35: warning: its scope is only this
definition or declaration, which is probably not what you want
./arch/m68k/include/asm/macintosh.h:20:36: warning: 'struct irq_data'
declared inside parameter list
extern void mac_irq_disable(struct irq_data *data);
The warning can be resolved with,
diff --git a/arch/m68k/include/asm/macintosh.h
b/arch/m68k/include/asm/macintosh.h
index d9a08bed4b12..f653b60f2afc 100644
--- a/arch/m68k/include/asm/macintosh.h
+++ b/arch/m68k/include/asm/macintosh.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
so that macintosh.h could be unconditionally included to avoid some
#ifdefs. That's just BTW. I don't object to your solution.
The MACH_IS_ATARI is not guaranteed to be compile time constant,
depending on what target options you have configured.
Actually, MACH_IS_ATARI is a compile-time constant when CONFIG_ATARI=n.
When I build that file with mac_defconfig and gcc 6.4, the C preprocessor
generates this:
if ((0))
unknown = amiga_parse_bootinfo(record);
else if ((0))
unknown = atari_parse_bootinfo(record);
else if ((1))
unknown = mac_parse_bootinfo(record);
else if ((0))
unknown = q40_parse_bootinfo(record);
else if ((0))
unknown = bvme6000_parse_bootinfo(record);
else if ((0))
unknown = mvme16x_parse_bootinfo(record);
else if ((0))
unknown = mvme147_parse_bootinfo(record);
else if ((0))
unknown = hp300_parse_bootinfo(record);
else if ((0))
unknown = apollo_parse_bootinfo(record);
else
unknown = 1;
We don't get that "implicit declaration" warning because the function
prototypes are all declared unconditionally at the top of the same file.
Anyway, the warning we were discussing was this one:
arch/m68k/kernel/setup_mm.c: In function 'm68k_nvram_get_size':
arch/m68k/kernel/setup_mm.c:605:10: error: implicit declaration of
function 'atari_nvram_get_size' [-Werror=implicit-function-declaration]
return atari_nvram_get_size();
This warning is the reason why commit d3b41b6bb49e ("m68k: Dispatch
nvram_ops calls to Atari or Mac functions") unconditionally included
atarihw.h.
It's annoying that we can't unconditionally include atarihw.h but I don't
have a solution for that.
The real issue is including , right?
I take it you meant to write not .
At first sight, the only reason for that is:
#define atari_readb raw_inb
#define atari_writeb raw_outb
#define atari_inb_p raw_inb
#define atari_outb_p raw_outb
Note that the first definition is unused, and the other 3 have only a handful
users.
At second sight, the include can just be removed, an Atari
kernel still builds fine...
Would that fix the issue?
Yes, it seems so. Thanks.
Here's the patch I tested.
diff --git a/arch/m68k/include/asm/atarihw.h b/arch/m68k/include/asm/atarihw.h
index 533008262b69..ba1889c1a933 100644
--- a/arch/m68k/include/asm/atarihw.h
+++ b/arch/m68k/include/asm/atarihw.h
@@ -22,7 +22,6 @@
#include
#include
-#include
#include
extern u_long atari_mch_cookie;
diff --git a/arch/m68k/include/asm/macintosh.h
b/arch/m68k/include/asm/macintosh.h
index d9a08bed4b12..f653b60f2afc 100644
--- a/arch/m68k/include/asm/macintosh.h
+++ b/arch/m68k/include/asm/macintosh.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
I built 4 configurations - coldfire (mmu), atari, mac, atari + mac.
It's hard to imagine that removing those extra #defines would be a problem
given that doing so doesn't lead to compiler warnings or errors. The atari
build booted up okay in aranym.
Works for me too. I prefer this solution.
Do you want to resend that patch with commit message and signed-off-by?
Regards
Greg
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
On Wed, 31 Jul 2019, Geert Uytterhoeven wrote:
> On Wed, Jul 31, 2019 at 9:47 AM Finn Thain wrote:
> > On Wed, 31 Jul 2019, Greg Ungerer wrote:
> > > No, not sufficient. You still get the following warnings after
> > > just moving that include of atarihw.h:
> > >
> > > CC arch/m68k/kernel/setup.o
> > > In file included from arch/m68k/kernel/setup_mm.c:48:0,
> > > from arch/m68k/kernel/setup.c:3:
> > > ./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data'
> > > declared inside parameter list
> > > extern void mac_irq_enable(struct irq_data *data);
> > >^
> > > ./arch/m68k/include/asm/macintosh.h:19:35: warning: its scope is only this
> > > definition or declaration, which is probably not what you want
> > > ./arch/m68k/include/asm/macintosh.h:20:36: warning: 'struct irq_data'
> > > declared inside parameter list
> > > extern void mac_irq_disable(struct irq_data *data);
> > >
> >
> > The warning can be resolved with,
> >
> > diff --git a/arch/m68k/include/asm/macintosh.h
> > b/arch/m68k/include/asm/macintosh.h
> > index d9a08bed4b12..f653b60f2afc 100644
> > --- a/arch/m68k/include/asm/macintosh.h
> > +++ b/arch/m68k/include/asm/macintosh.h
> > @@ -4,6 +4,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > so that macintosh.h could be unconditionally included to avoid some
> > #ifdefs. That's just BTW. I don't object to your solution.
> >
> > >
> > > The MACH_IS_ATARI is not guaranteed to be compile time constant,
> > > depending on what target options you have configured.
> > >
> >
> > Actually, MACH_IS_ATARI is a compile-time constant when CONFIG_ATARI=n.
> >
> > When I build that file with mac_defconfig and gcc 6.4, the C preprocessor
> > generates this:
> >
> >if ((0))
> > unknown = amiga_parse_bootinfo(record);
> >else if ((0))
> > unknown = atari_parse_bootinfo(record);
> >else if ((1))
> > unknown = mac_parse_bootinfo(record);
> >else if ((0))
> > unknown = q40_parse_bootinfo(record);
> >else if ((0))
> > unknown = bvme6000_parse_bootinfo(record);
> >else if ((0))
> > unknown = mvme16x_parse_bootinfo(record);
> >else if ((0))
> > unknown = mvme147_parse_bootinfo(record);
> >else if ((0))
> > unknown = hp300_parse_bootinfo(record);
> >else if ((0))
> > unknown = apollo_parse_bootinfo(record);
> >else
> > unknown = 1;
> >
> > We don't get that "implicit declaration" warning because the function
> > prototypes are all declared unconditionally at the top of the same file.
> >
> > Anyway, the warning we were discussing was this one:
> >
> > arch/m68k/kernel/setup_mm.c: In function 'm68k_nvram_get_size':
> > arch/m68k/kernel/setup_mm.c:605:10: error: implicit declaration of
> > function 'atari_nvram_get_size' [-Werror=implicit-function-declaration]
> >return atari_nvram_get_size();
> >
> > This warning is the reason why commit d3b41b6bb49e ("m68k: Dispatch
> > nvram_ops calls to Atari or Mac functions") unconditionally included
> > atarihw.h.
> >
> > It's annoying that we can't unconditionally include atarihw.h but I don't
> > have a solution for that.
>
> The real issue is including , right?
>
I take it you meant to write not .
> At first sight, the only reason for that is:
>
> #define atari_readb raw_inb
> #define atari_writeb raw_outb
>
> #define atari_inb_p raw_inb
> #define atari_outb_p raw_outb
>
> Note that the first definition is unused, and the other 3 have only a handful
> users.
>
> At second sight, the include can just be removed, an Atari
> kernel still builds fine...
>
> Would that fix the issue?
>
Yes, it seems so. Thanks.
Here's the patch I tested.
diff --git a/arch/m68k/include/asm/atarihw.h b/arch/m68k/include/asm/atarihw.h
index 533008262b69..ba1889c1a933 100644
--- a/arch/m68k/include/asm/atarihw.h
+++ b/arch/m68k/include/asm/atarihw.h
@@ -22,7 +22,6 @@
#include
#include
-#include
#include
extern u_long atari_mch_cookie;
diff --git a/arch/m68k/include/asm/macintosh.h
b/arch/m68k/include/asm/macintosh.h
index d9a08bed4b12..f653b60f2afc 100644
--- a/arch/m68k/include/asm/macintosh.h
+++ b/arch/m68k/include/asm/macintosh.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
I built 4 configurations - coldfire (mmu), atari, mac, atari + mac.
It's hard to imagine that removing those extra #defines would be a problem
given that doing so doesn't lead to compiler warnings or errors. The atari
build booted up okay in aranym.
--
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
>
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
Hi Finn,
On Wed, Jul 31, 2019 at 9:47 AM Finn Thain wrote:
> On Wed, 31 Jul 2019, Greg Ungerer wrote:
> > No, not sufficient. You still get the following warnings after
> > just moving that include of atarihw.h:
> >
> > CC arch/m68k/kernel/setup.o
> > In file included from arch/m68k/kernel/setup_mm.c:48:0,
> > from arch/m68k/kernel/setup.c:3:
> > ./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data'
> > declared inside parameter list
> > extern void mac_irq_enable(struct irq_data *data);
> >^
> > ./arch/m68k/include/asm/macintosh.h:19:35: warning: its scope is only this
> > definition or declaration, which is probably not what you want
> > ./arch/m68k/include/asm/macintosh.h:20:36: warning: 'struct irq_data'
> > declared inside parameter list
> > extern void mac_irq_disable(struct irq_data *data);
> >
>
> The warning can be resolved with,
>
> diff --git a/arch/m68k/include/asm/macintosh.h
> b/arch/m68k/include/asm/macintosh.h
> index d9a08bed4b12..f653b60f2afc 100644
> --- a/arch/m68k/include/asm/macintosh.h
> +++ b/arch/m68k/include/asm/macintosh.h
> @@ -4,6 +4,7 @@
>
> #include
> #include
> +#include
>
> #include
>
> so that macintosh.h could be unconditionally included to avoid some
> #ifdefs. That's just BTW. I don't object to your solution.
>
> >
> > The MACH_IS_ATARI is not guaranteed to be compile time constant,
> > depending on what target options you have configured.
> >
>
> Actually, MACH_IS_ATARI is a compile-time constant when CONFIG_ATARI=n.
>
> When I build that file with mac_defconfig and gcc 6.4, the C preprocessor
> generates this:
>
>if ((0))
> unknown = amiga_parse_bootinfo(record);
>else if ((0))
> unknown = atari_parse_bootinfo(record);
>else if ((1))
> unknown = mac_parse_bootinfo(record);
>else if ((0))
> unknown = q40_parse_bootinfo(record);
>else if ((0))
> unknown = bvme6000_parse_bootinfo(record);
>else if ((0))
> unknown = mvme16x_parse_bootinfo(record);
>else if ((0))
> unknown = mvme147_parse_bootinfo(record);
>else if ((0))
> unknown = hp300_parse_bootinfo(record);
>else if ((0))
> unknown = apollo_parse_bootinfo(record);
>else
> unknown = 1;
>
> We don't get that "implicit declaration" warning because the function
> prototypes are all declared unconditionally at the top of the same file.
>
> Anyway, the warning we were discussing was this one:
>
> arch/m68k/kernel/setup_mm.c: In function 'm68k_nvram_get_size':
> arch/m68k/kernel/setup_mm.c:605:10: error: implicit declaration of
> function 'atari_nvram_get_size' [-Werror=implicit-function-declaration]
>return atari_nvram_get_size();
>
> This warning is the reason why commit d3b41b6bb49e ("m68k: Dispatch
> nvram_ops calls to Atari or Mac functions") unconditionally included
> atarihw.h.
>
> It's annoying that we can't unconditionally include atarihw.h but I don't
> have a solution for that.
The real issue is including , right?
At first sight, the only reason for that is:
#define atari_readb raw_inb
#define atari_writeb raw_outb
#define atari_inb_p raw_inb
#define atari_outb_p raw_outb
Note that the first definition is unused, and the other 3 have only a handful
users.
At second sight, the include can just be removed, an Atari
kernel still builds fine...
Would that fix the issue?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
On Wed, 31 Jul 2019, Greg Ungerer wrote:
> No, not sufficient. You still get the following warnings after
> just moving that include of atarihw.h:
>
> CC arch/m68k/kernel/setup.o
> In file included from arch/m68k/kernel/setup_mm.c:48:0,
> from arch/m68k/kernel/setup.c:3:
> ./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data'
> declared inside parameter list
> extern void mac_irq_enable(struct irq_data *data);
>^
> ./arch/m68k/include/asm/macintosh.h:19:35: warning: its scope is only this
> definition or declaration, which is probably not what you want
> ./arch/m68k/include/asm/macintosh.h:20:36: warning: 'struct irq_data'
> declared inside parameter list
> extern void mac_irq_disable(struct irq_data *data);
>
The warning can be resolved with,
diff --git a/arch/m68k/include/asm/macintosh.h
b/arch/m68k/include/asm/macintosh.h
index d9a08bed4b12..f653b60f2afc 100644
--- a/arch/m68k/include/asm/macintosh.h
+++ b/arch/m68k/include/asm/macintosh.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
so that macintosh.h could be unconditionally included to avoid some
#ifdefs. That's just BTW. I don't object to your solution.
>
> The MACH_IS_ATARI is not guaranteed to be compile time constant,
> depending on what target options you have configured.
>
Actually, MACH_IS_ATARI is a compile-time constant when CONFIG_ATARI=n.
When I build that file with mac_defconfig and gcc 6.4, the C preprocessor
generates this:
if ((0))
unknown = amiga_parse_bootinfo(record);
else if ((0))
unknown = atari_parse_bootinfo(record);
else if ((1))
unknown = mac_parse_bootinfo(record);
else if ((0))
unknown = q40_parse_bootinfo(record);
else if ((0))
unknown = bvme6000_parse_bootinfo(record);
else if ((0))
unknown = mvme16x_parse_bootinfo(record);
else if ((0))
unknown = mvme147_parse_bootinfo(record);
else if ((0))
unknown = hp300_parse_bootinfo(record);
else if ((0))
unknown = apollo_parse_bootinfo(record);
else
unknown = 1;
We don't get that "implicit declaration" warning because the function
prototypes are all declared unconditionally at the top of the same file.
Anyway, the warning we were discussing was this one:
arch/m68k/kernel/setup_mm.c: In function 'm68k_nvram_get_size':
arch/m68k/kernel/setup_mm.c:605:10: error: implicit declaration of
function 'atari_nvram_get_size' [-Werror=implicit-function-declaration]
return atari_nvram_get_size();
This warning is the reason why commit d3b41b6bb49e ("m68k: Dispatch
nvram_ops calls to Atari or Mac functions") unconditionally included
atarihw.h.
It's annoying that we can't unconditionally include atarihw.h but I don't
have a solution for that.
If the convention is to put #ifdef around code like that then I guess
that's what we should do here too...
Reviewed-by: Finn Thain
--
> Regards
> Greg
>
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
Hi Finn,
On 31/7/19 3:36 pm, Finn Thain wrote:
On Mon, 29 Jul 2019,g...@kernel.org wrote:
From: Greg Ungerer
Commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari
or Mac functions") causes a number of compile time warnings
to be generated if compiling for a ColdFire MMU enabled target:
In file included from ./arch/m68k/include/asm/atarihw.h:25:0,
from arch/m68k/kernel/setup_mm.c:41,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/raw_io.h:39:0: warning: "__raw_readb" redefined
#define __raw_readb in_8
^
In file included from ./arch/m68k/include/asm/io.h:6:0,
from arch/m68k/kernel/setup_mm.c:36,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/io_no.h:16:0: note: this is the location of the
previous definition
#define __raw_readb(addr) \
^
...
It appears that I neglected to build test that patch for coldfire. Sorry
about that.
:-)
The most strait forward fix is to conditionaly include only
those headers actually required, and to only check for
machine types that are configured/enabled into this build.
Signed-off-by: Greg Ungerer
---
arch/m68k/kernel/setup_mm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 528484feff80..04853f68f7a8 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -38,14 +38,16 @@
#ifdef CONFIG_AMIGA
#include
#endif
-#include
#ifdef CONFIG_ATARI
+#include
#include
#endif
Is that change not sufficient to avoid the new warnings?
No, not sufficient. You still get the following warnings after
just moving that include of atarihw.h:
CC arch/m68k/kernel/setup.o
In file included from arch/m68k/kernel/setup_mm.c:48:0,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/macintosh.h:19:35: warning: ‘struct irq_data’ declared
inside parameter list
extern void mac_irq_enable(struct irq_data *data);
^
./arch/m68k/include/asm/macintosh.h:19:35: warning: its scope is only this
definition or declaration, which is probably not what you want
./arch/m68k/include/asm/macintosh.h:20:36: warning: ‘struct irq_data’ declared
inside parameter list
extern void mac_irq_disable(struct irq_data *data);
^
#ifdef CONFIG_SUN3X
#include
#endif
+#ifdef CONFIG_MAC
#include
+#endif
#include
#if !FPSTATESIZE || !NR_IRQS
Can we avoid this ifdef?
This ifdef fixes the warnings I listed above.
@@ -602,10 +604,14 @@ static long m68k_nvram_initialize(void)
static ssize_t m68k_nvram_get_size(void)
{
+#ifdef CONFIG_ATARI
if (MACH_IS_ATARI)
return atari_nvram_get_size();
- else if (MACH_IS_MAC)
+#endif
+#ifdef CONFIG_MAC
+ if (MACH_IS_MAC)
return mac_pram_get_size();
+#endif
The MACH_IS_ATARI and MACH_IS_MAC macros already appear unconditionally in
this file in m68k_parse_bootinfo(). Can we avoid these ifdefs too?
If the MACH_IS_* macros can no longer be used unconditionally, would it
not be better to find a way to allow this?
It is not the presence of the macros that ends up being the problem.
It is the functions, atari_nvram_get_size() and mac_pram_get_size().
Without these ifdefs here if you try to compile for the mac_defconfig
you get the following errors at compile time:
CC arch/m68k/kernel/setup.o
In file included from arch/m68k/kernel/setup.c:3:0:
arch/m68k/kernel/setup_mm.c: In function ‘m68k_nvram_get_size’:
arch/m68k/kernel/setup_mm.c:608:10: error: implicit declaration of function
‘atari_nvram_get_size’ [-Werror=implicit-function-declaration]
return atari_nvram_get_size();
^
cc1: some warnings being treated as errors
scripts/Makefile.build:273: recipe for target 'arch/m68k/kernel/setup.o' failed
make[1]: *** [arch/m68k/kernel/setup.o] Error 1
The MACH_IS_ATARI is not guaranteed to be compile time constant,
depending on what target options you have configured.
Regards
Greg
Re: [PATCH] m68k: fix ColdFire with MMU compile warnings
On Mon, 29 Jul 2019, g...@kernel.org wrote:
> From: Greg Ungerer
>
> Commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari
> or Mac functions") causes a number of compile time warnings
> to be generated if compiling for a ColdFire MMU enabled target:
>
> In file included from ./arch/m68k/include/asm/atarihw.h:25:0,
> from arch/m68k/kernel/setup_mm.c:41,
> from arch/m68k/kernel/setup.c:3:
> ./arch/m68k/include/asm/raw_io.h:39:0: warning: "__raw_readb" redefined
> #define __raw_readb in_8
> ^
> In file included from ./arch/m68k/include/asm/io.h:6:0,
> from arch/m68k/kernel/setup_mm.c:36,
> from arch/m68k/kernel/setup.c:3:
> ./arch/m68k/include/asm/io_no.h:16:0: note: this is the location of the
> previous definition
> #define __raw_readb(addr) \
> ^
> ...
>
It appears that I neglected to build test that patch for coldfire. Sorry
about that.
> The most strait forward fix is to conditionaly include only
> those headers actually required, and to only check for
> machine types that are configured/enabled into this build.
>
> Signed-off-by: Greg Ungerer
> ---
> arch/m68k/kernel/setup_mm.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> index 528484feff80..04853f68f7a8 100644
> --- a/arch/m68k/kernel/setup_mm.c
> +++ b/arch/m68k/kernel/setup_mm.c
> @@ -38,14 +38,16 @@
> #ifdef CONFIG_AMIGA
> #include
> #endif
> -#include
> #ifdef CONFIG_ATARI
> +#include
> #include
> #endif
Is that change not sufficient to avoid the new warnings?
> #ifdef CONFIG_SUN3X
> #include
> #endif
> +#ifdef CONFIG_MAC
> #include
> +#endif
> #include
>
> #if !FPSTATESIZE || !NR_IRQS
Can we avoid this ifdef?
> @@ -602,10 +604,14 @@ static long m68k_nvram_initialize(void)
>
> static ssize_t m68k_nvram_get_size(void)
> {
> +#ifdef CONFIG_ATARI
> if (MACH_IS_ATARI)
> return atari_nvram_get_size();
> - else if (MACH_IS_MAC)
> +#endif
> +#ifdef CONFIG_MAC
> + if (MACH_IS_MAC)
> return mac_pram_get_size();
> +#endif
The MACH_IS_ATARI and MACH_IS_MAC macros already appear unconditionally in
this file in m68k_parse_bootinfo(). Can we avoid these ifdefs too?
If the MACH_IS_* macros can no longer be used unconditionally, would it
not be better to find a way to allow this?
--
> return -ENODEV;
> }
>
> --
> 2.17.1
>
>
Re: [PATCH 2/2] drivers/ata: convert pata_falcon to arch platform device
Hi! On 7/2/19 2:51 PM, Bartlomiej Zolnierkiewicz wrote: > On 7/2/19 12:02 AM, Michael Schmitz wrote: >> The Atari platform device setup now provides a platform device >> for the Falcon IDE interface. Use this in place of the simple platform >> device set up in the old pata_falcon probe code. >> >> Signed-off-by: Michael Schmitz > > Acked-by: Bartlomiej Zolnierkiewicz Have these patches been pushed to any tree yet? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH] m68k: fix ColdFire with MMU compile warnings
From: Greg Ungerer
Commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari
or Mac functions") causes a number of compile time warnings
to be generated if compiling for a ColdFire MMU enabled target:
In file included from ./arch/m68k/include/asm/atarihw.h:25:0,
from arch/m68k/kernel/setup_mm.c:41,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/raw_io.h:39:0: warning: "__raw_readb" redefined
#define __raw_readb in_8
^
In file included from ./arch/m68k/include/asm/io.h:6:0,
from arch/m68k/kernel/setup_mm.c:36,
from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/io_no.h:16:0: note: this is the location of the
previous definition
#define __raw_readb(addr) \
^
...
The most strait forward fix is to conditionaly include only
those headers actually required, and to only check for
machine types that are configured/enabled into this build.
Signed-off-by: Greg Ungerer
---
arch/m68k/kernel/setup_mm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 528484feff80..04853f68f7a8 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -38,14 +38,16 @@
#ifdef CONFIG_AMIGA
#include
#endif
-#include
#ifdef CONFIG_ATARI
+#include
#include
#endif
#ifdef CONFIG_SUN3X
#include
#endif
+#ifdef CONFIG_MAC
#include
+#endif
#include
#if !FPSTATESIZE || !NR_IRQS
@@ -602,10 +604,14 @@ static long m68k_nvram_initialize(void)
static ssize_t m68k_nvram_get_size(void)
{
+#ifdef CONFIG_ATARI
if (MACH_IS_ATARI)
return atari_nvram_get_size();
- else if (MACH_IS_MAC)
+#endif
+#ifdef CONFIG_MAC
+ if (MACH_IS_MAC)
return mac_pram_get_size();
+#endif
return -ENODEV;
}
--
2.17.1
Hello Dear Friend
Hello Dear Friend. I’m Mrs. Stellar Maoris a manger in HSBC bank of Spain Madrid, I am sending this brief letter to seek for your partnership and long term relationship, I have an important and urgent issue I want to discuss with you privately about Transaction fund worth the sum of $9.5m America dollars left by most of the greedy Asia Kuwait politician in our bank here in Spain Madrid A fund which suppose to have been use to develop the continent. If you know that you can invest this fund into profitable business in your country by the end we shall have 50%50 share each, kindly get back to me for more detail and procedures. Your urgent respond will be highly appreciated Awaiting to hear from you asap. My Regard. Stellar Maoris Contact Me Through My Personal Email ID: stellerba...@barid.com Phone Number: +34(62) 768 5146
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Joachim,
On 25/7/19 6:26 am, Joachim Dietrich wrote:
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is
done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a
wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the
CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack
Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have
separate
stack pointers, but they're not USP and SSP, like on classic m68k
and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct.
But
I'm a little bit confused about the stack pointer handling of
the v3
The stack pointer handling (or really the presence of A7 and
other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.
coldfire, because in the reference manual of the mcf5329 stands:
"To
support dual stack pointers, the following two supervisor
instructions
are included in the ColdFire instruction set architecture to
load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26,
this
was
the default handling for the mcf5329.
That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact
version
I included it). The addition of 2 A7 registers and supporting
instructions
was introduced in the ColdFire ISA_A+ version of the instruction
set.
(So generally speaking old ColdFire parts don't have them, newer
ones
do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single
unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed
for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution
for
mcf5329, or perhaps it needs some special handling for A7 vs.
OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15)
fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.
The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.
The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.
So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see
arch/m68k/include/asm/m53xxacr.h).
Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?
OK. I will do that. But at first glance everything looks right (in
the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.
Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.
The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.
Can you try the patch below?
I did it,
It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.
but for me it looks as if the patch has fixed only the described
problem, but the handling doesn't seem to work quite yet. But let me
explained this in more detail:
Without your patch, the kernel starts until the first user process. Let
this be a simple "Hello World", which prints the argv[0] and argv. In
this case usp points to a wrong address; the user process has no
arguments. No chance to start an init process.
With the new patch, the (same "Hello World") usp seems to points to a
correct address. The arguments are correct. So, I guess the EUSP Bit in
CACR is set.
But when I want to start the BusyBox init then I get a trap:
---
...
[2.78] This architecture does not have kernel memory protection.
[2.78] Run /sbin/init as init process
init started: BusyBox v1.29.3 (2019-06-04 13:30:06 CEST)
[3.31] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 01fa, exited with 01f9?
[3.32] softirq: huh, entered softirq 3 NET_RX (ptrval) with
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Greg,
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is
done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a
wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the
CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack
Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have
separate
stack pointers, but they're not USP and SSP, like on classic m68k
and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct.
But
I'm a little bit confused about the stack pointer handling of
the v3
The stack pointer handling (or really the presence of A7 and
other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.
coldfire, because in the reference manual of the mcf5329 stands:
"To
support dual stack pointers, the following two supervisor
instructions
are included in the ColdFire instruction set architecture to
load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26,
this
was
the default handling for the mcf5329.
That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact
version
I included it). The addition of 2 A7 registers and supporting
instructions
was introduced in the ColdFire ISA_A+ version of the instruction
set.
(So generally speaking old ColdFire parts don't have them, newer
ones
do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single
unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed
for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution
for
mcf5329, or perhaps it needs some special handling for A7 vs.
OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15)
fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.
The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.
The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.
So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see
arch/m68k/include/asm/m53xxacr.h).
Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?
OK. I will do that. But at first glance everything looks right (in
the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.
Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.
The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.
Can you try the patch below?
I did it,
It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.
but for me it looks as if the patch has fixed only the described
problem, but the handling doesn't seem to work quite yet. But let me
explained this in more detail:
Without your patch, the kernel starts until the first user process. Let
this be a simple "Hello World", which prints the argv[0] and argv. In
this case usp points to a wrong address; the user process has no
arguments. No chance to start an init process.
With the new patch, the (same "Hello World") usp seems to points to a
correct address. The arguments are correct. So, I guess the EUSP Bit in
CACR is set.
But when I want to start the BusyBox init then I get a trap:
---
...
[2.78] This architecture does not have kernel memory protection.
[2.78] Run /sbin/init as init process
init started: BusyBox v1.29.3 (2019-06-04 13:30:06 CEST)
[3.31] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 01fa, exited with 01f9?
[3.32] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 0100, exited with 00f9?
LOANS !!!
Dial Direct Loan SA Consolidate your debts with Dial Direct Loan SA for your peace of mind at a fixed interest rate of 4.75%,personal and business loans are also welcome.For details file in your applications by sending an email to:dialdirectloan...@mail2consultant.com. Yours in Service, Susan Muller (Mrs.), Senior Consultant, Loan Application Team Dial Direct Loan SA Tel No: +27717231058
Great News: National Heart Center Singapore CT Coronary Calcium Score 18 July 2019
Subject: Great News: National Heart Center Singapore CT Coronary Calcium Score 18 July 2019 Good day from Singapore, This is good news for trillions and trillions of years to come! 1. My weight/mass is 123.5 kg (taken on 23 July 2019). 2. My height is 1.79 meters (taken on 23 July 2019). 3. My Body Mass Index (BMI) is 38.56 kg/m2 (as at 23 July 2019) 4. I have been living with random, intermittent, and chronic mild chest pain for the past 10 years since the year 2009. 5. I have seen countless (lost count) doctors in Singapore over the past 10 years. The diagnoses were always atypical chest pain (ie. nothing to do with the heart). All the doctors I have seen did not think it is angina pectoris. 6. I have done countless (lost count) cardiac tests in Singapore over the past 10 years, including electrocardiogram (ECG), treadmill stress test, MIBI heart perfusion test, and CT coronary angiogram. All the test results were either normal or perfect. 7. I have high cholesterol (hypercholesterolemia) for many years, according to doctors. 8. My pulse rate is consistently around 100 beats per minute for many years. 9. Recently, I went for CT coronary calcium scoring at National Heart Center Singapore (NHCS) on 18 July 2019. The following is a transcript of the CT coronary calcium scoring report obtained on 23 July 2019. -BEGIN NHCS CT Coronary Calcium Scoring Report 18 July 2019- National Heart Centre Singapore Patient Results Requested By: Chan Lihua Laura (Doctor) 23-Jul-2019 05:54 PM TURRITOPSIS DOHRNII TEO EN MING (ZHANG ENMING)Sex: M Age: 41yDOB: * MRN / Visit No.: * / H119042968E0003Locn: NHC-Cardiac Clinic B 18-Jul-2019 11:07 CT Coronary Calcium Scoring HCCT195011991718Final Additional Info Verified Date/Time: 18/07/2019 12:02 Final Verified Person: Dr. Narayan Lath Verified Section: NHC CT Performed at : National Heart Centre Singapore Level 5, 5D, 5 Hospital Drive Singapore 169609 CT Coronary Calcium Final Scoring HISTORY to reassess risk profile TECHNIQUE Calcium Scan was prospectively gated. Images were reconstructed at 3.0 mm slice thickness. Assessment was done using Vitrea Calcium software and Agatston scoring schema. REPORT Calcium Score: Agatston 0 , Volume score 0 mm3, LM 0 , RCA 0 , LAD 0 , LCX 0. The calcium score is between 0 th and 25 th percentile for [men between the ages of 40 and 44. Normal coronary origins. EXTRACARDIAC FINDINGS No incidental significant abnormalities in the included lungs or mediastinum. Report Indicator: Normal Finalised by:Narayan Lath, Senior Consultant, 12598I Finalised Date/Time: 18/07/2019 12:02 Report Link Final Printed from: National Heart Centre SingaporeEnd of Report Page: 1 of 1 -END NHCS CT Coronary Calcium Scoring Report 18 July 2019- For scanned image of the original CT coronary calcium scoring report from National Heart Center Singapore, please visit my RAID 1 mirroring redundant Blogger and Wordpress blogs at https://tdtemcerts.blogspot.sg https://tdtemcerts.wordpress.com On how to interpret CT Coronary Calcium Score, please visit the website of the Radiological Society of North America, Inc. (RSNA) at https://www.radiologyinfo.org/en/info.cfm?pg=ct_calscoring -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Joachim,
On 10/7/19 5:04 am, Joachim Dietrich wrote:
On 4/7/19 4:37 am, Joachim Dietrich wrote:
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is
done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a
wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack
Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k
and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct.
But
I'm a little bit confused about the stack pointer handling of the v3
The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.
coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor
instructions
are included in the ColdFire instruction set architecture to
load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this
was
the default handling for the mcf5329.
That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting
instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones
do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single
unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution
for
mcf5329, or perhaps it needs some special handling for A7 vs.
OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15)
fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.
The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.
The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.
So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see
arch/m68k/include/asm/m53xxacr.h).
Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?
OK. I will do that. But at first glance everything looks right (in the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.
Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.
The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.
Can you try the patch below?
I did it,
It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.
but for me it looks as if the patch has fixed only the described
problem, but the handling doesn't seem to work quite yet. But let me
explained this in more detail:
Without your patch, the kernel starts until the first user process. Let
this be a simple "Hello World", which prints the argv[0] and argv. In
this case usp points to a wrong address; the user process has no
arguments. No chance to start an init process.
With the new patch, the (same "Hello World") usp seems to points to a
correct address. The arguments are correct. So, I guess the EUSP Bit in
CACR is set.
But when I want to start the BusyBox init then I get a trap:
---
...
[2.78] This architecture does not have kernel memory protection.
[2.78] Run /sbin/init as init process
init started: BusyBox v1.29.3 (2019-06-04 13:30:06 CEST)
[3.31] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 01fa, exited with 01f9?
[3.32] softirq:
If interested
My name is Mr. Allen, I have a Business Proposal of Four million five hundred thousand united states dollars for you to handle with me from my bank. I will need you to assist me in executing this Business .
Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
Hi,
On Sun, Jul 14, 2019 at 06:08:20PM +1000, Finn Thain wrote:
> On Sun, 14 Jul 2019, Mike Rapoport wrote:
>
> > > >
> > > > Even with those fixes I'm still concerned about the
> > > > SECTION_SIZE_BITS and MAX_PHYSMEM_BITS definitions.
> > > >
> > > > Without implementing vmemmap support we are limited in their maximal
> > > > difference by 8 bits. That means that either minimal section size
> > > > would be 16M or the maximal physical memory size would be limited to
> > > > 1G. I'm not that familiar with m68k machine variants to say if
> > > > either of these assumptions can be used.
> > >
> > > While an Amiga could, in theory, have ca. 3.8 GiB of RAM, in practice
> > > it's limited to 1 GiB, but most machines have only a fraction of that.
> > > AFAIK, other m68k machines are similar. So a limit of 1 GiB sounds
> > > fine to me.
> > >
> > > But what's the impact of the minimal section size? What does it really
> > > mean?
> > > As my A4000 has 12 MiB of RAM at 0x740, and that seems to work, it
> > > does not mean that address and size must be a multiple of 16 MiB?
> > >
> > > Memory configuration varies wildly among machines.
> > > IIRC, some Macs can have several discontiguous 1 MiB blocks.
> >
> > Each section has a contiguous memory map for [section_start, section_end).
> > The section_start is SECTION_SIZE * section_nr.
> > The section_end is either SECTION_SIZE * (section_nr + 1) if the entire
> > section is populated or the end address of the memory chunk belonging to
> > that section.
> >
> > For instance, with SECTION_SIZE of 16MiB your A4000 would have
> > section_start at 0x740 and section_end at 0x800.
> > If we were using, say, 8MiB sections, it would have two sections populated:
> > [0x740, 0x7c0), [0x7c0, 0x800].
> >
> > The issue with having section size too big is that for machines that have
> > small chunks of discontiguous memory separated by less than SECTION_SIZE,
> > these chunks will map to the same section and this will cause creation of
> > unused memmap for the hole between those chunks.
> >
> > E.g. with two chunks of 1MiB located at 0 and 14MiB, we'll have a single
> > section spanning 15MiB with wasted memory map covering the hole between 1M
> > and 14MiB.
> >
> > On the other hand, presuming we want MAX_PHYSMEM_BITS set to 32, making the
> > SECTION_SIZE smaller won't work because we are running out of space in the
> > page flags :(
> >
>
> What about a Kconfig choice between say, two alternatives, an embedded (or
> vintage) system and an emulated (or modified) system?
>
> IIUC, a 1 MB section size would constrain physical memory to 256 MB which
> seems reasonable for the former kind of system, while the latter would
> have a 16 MB section size.
>
> Perhaps additional Kconfig options, such as a 4 MB section size, could be
> added later as and when the need arises?
We can add a Kconfig knob, but I'd prefer to avoid it and to have memory
model selection as simple and automated as possible.
I'll try to see what are the trade-offs of adding vmemmap or implementing
ARCH_HAS_HOLES_MEMORYMODEL to free holes in the flat memory map.
> --
>
> > > Thanks!
> > >
> > > Gr{oetje,eeting}s,
> > >
> > > Geert
> > >
> > > --
> > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > > ge...@linux-m68k.org
> > >
> > > In personal conversations with technical people, I call myself a hacker.
> > > But
> > > when I'm talking to journalists I just say "programmer" or something like
> > > that.
> > > -- Linus Torvalds
> >
> >
--
Sincerely yours,
Mike.
Kindly Respond
Hello, I am Barr Fredrick Mbogo a business consultant i have a lucrative business to discuss with you from the Eastern part of Africa Uganda to be precise aimed at agreed percentage upon your acceptance of my hand in business and friendship. Kindly respond to me if you are interested to partner with me for an update. Very important. Yours Sincerely, Donald Douglas, For, Barr Frederick Mbogo Legal Consultant. Reply to: barrfredmb...@consultant.com
Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
On 7/12/19 5:08 PM, Andreas Schwab wrote: > On Jul 12 2019, Geert Uytterhoeven wrote: > >> While an Amiga could, in theory, have ca. 3.8 GiB of RAM, in practice >> it's limited to 1 GiB, but most machines have only a fraction of that. >> AFAIK, other m68k machines are similar. So a limit of 1 GiB sounds fine >> to me. > > That would severly limit the usefulness of emulators like Aranym. I agree with that stance. The kernel can use more memory on Aranym than on currently available real hardware and changes to the memory management in the kernel should not limit that functionality. Also, I expect the Vampire FPGA-based accelerators [1] to become usable with Linux in the future and those could see more on-board memory as well. Adrian > [1] https://www.apollo-accelerators.com/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
On Sun, 14 Jul 2019, Mike Rapoport wrote:
> > >
> > > Even with those fixes I'm still concerned about the
> > > SECTION_SIZE_BITS and MAX_PHYSMEM_BITS definitions.
> > >
> > > Without implementing vmemmap support we are limited in their maximal
> > > difference by 8 bits. That means that either minimal section size
> > > would be 16M or the maximal physical memory size would be limited to
> > > 1G. I'm not that familiar with m68k machine variants to say if
> > > either of these assumptions can be used.
> >
> > While an Amiga could, in theory, have ca. 3.8 GiB of RAM, in practice
> > it's limited to 1 GiB, but most machines have only a fraction of that.
> > AFAIK, other m68k machines are similar. So a limit of 1 GiB sounds
> > fine to me.
> >
> > But what's the impact of the minimal section size? What does it really
> > mean?
> > As my A4000 has 12 MiB of RAM at 0x740, and that seems to work, it
> > does not mean that address and size must be a multiple of 16 MiB?
> >
> > Memory configuration varies wildly among machines.
> > IIRC, some Macs can have several discontiguous 1 MiB blocks.
>
> Each section has a contiguous memory map for [section_start, section_end).
> The section_start is SECTION_SIZE * section_nr.
> The section_end is either SECTION_SIZE * (section_nr + 1) if the entire
> section is populated or the end address of the memory chunk belonging to
> that section.
>
> For instance, with SECTION_SIZE of 16MiB your A4000 would have
> section_start at 0x740 and section_end at 0x800.
> If we were using, say, 8MiB sections, it would have two sections populated:
> [0x740, 0x7c0), [0x7c0, 0x800].
>
> The issue with having section size too big is that for machines that have
> small chunks of discontiguous memory separated by less than SECTION_SIZE,
> these chunks will map to the same section and this will cause creation of
> unused memmap for the hole between those chunks.
>
> E.g. with two chunks of 1MiB located at 0 and 14MiB, we'll have a single
> section spanning 15MiB with wasted memory map covering the hole between 1M
> and 14MiB.
>
> On the other hand, presuming we want MAX_PHYSMEM_BITS set to 32, making the
> SECTION_SIZE smaller won't work because we are running out of space in the
> page flags :(
>
What about a Kconfig choice between say, two alternatives, an embedded (or
vintage) system and an emulated (or modified) system?
IIUC, a 1 MB section size would constrain physical memory to 256 MB which
seems reasonable for the former kind of system, while the latter would
have a 16 MB section size.
Perhaps additional Kconfig options, such as a 4 MB section size, could be
added later as and when the need arises?
--
> > Thanks!
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > ge...@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like
> > that.
> > -- Linus Torvalds
>
>
Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
Hi Geert,
On Fri, Jul 12, 2019 at 04:28:26PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Fri, Jul 5, 2019 at 9:25 PM Mike Rapoport wrote:
> > On Mon, Jul 01, 2019 at 01:56:25PM +0200, Geert Uytterhoeven wrote:
> > > On Sun, Jun 30, 2019 at 10:58 AM Mike Rapoport wrote:
> > > > On Sun, Jun 30, 2019 at 12:54:49PM +1200, Michael Schmitz wrote:
> > > > > Am 29.06.2019 um 23:30 schrieb Mike Rapoport:
> > > > > >On Thu, Jun 20, 2019 at 06:46:28PM +0200, Geert Uytterhoeven wrote:
> > > > > >>On Wed, Jun 19, 2019 at 4:18 PM Mike Rapoport
> > > > > >>wrote:
> > > > > >>>On Wed, Jun 19, 2019 at 09:39:40AM +0200, Geert Uytterhoeven wrote:
> > > > > On Wed, Jun 19, 2019 at 9:06 AM Geert Uytterhoeven
> > > > > wrote:
> > > > > >On Tue, Jun 18, 2019 at 8:10 AM Mike Rapoport
> > > > > > wrote:
> > > > > >>
> > > > > >>Thanks, that hack did fix CONFIG_SINGLE_MEMORY_CHUNK=y.
> > > > > >>
> > > > > >>Back to sparsemem...
> > > > > >>
> > > > > >>With CONFIG_SINGLE_MEMORY_CHUNK=n, and CONFIG_SPARSEMEM=y,
> > > > > >>it also fails. Diff between working single memory chunk and failing
> > > > > >>sparsemem:
> > > > > >>
> > > > > >> -Memory: 7796K/12288K available (2555K kernel code, 259K rwdata,
> > > > > >>700K rodata, 136K init, 153K bss, 4492K reserved, 0K cma-reserved)
> > > > > >> +Memory: 7816K/131072K available (2556K kernel code, 261K rwdata,
> > > > > >>700K rodata, 136K init, 157K bss, 123256K reserved, 0K cma-reserved)
> > > > > >>
> > > > > >>Oops, looks like it thinks there's memory from
> > > > > >>0x-0x0800,
> > > > > >>instead of 0x0740-0x0800.
> > > > > >
> > > > > >Yeah, I've made a mistake in the zone/hole size calculations as it
> > > > > >seems.
> > > > > >
> > > > > >Can you try this:
> > > > > >
> > > > > >diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
> > > > > >index 87d09942be5c..bf438a0da173 100644
> > > > > >--- a/arch/m68k/mm/motorola.c
> > > > > >+++ b/arch/m68k/mm/motorola.c
> > > > > >@@ -229,10 +229,8 @@ static void m68k_free_area_init(unsigned long
> > > > > >max_addr)
> > > > > > memblock_set_bottom_up(true);
> > > > > >
> > > > > > zones_size[ZONE_DMA] = max_addr >> PAGE_SHIFT;
> > > > > >-if (m68k_num_memory > 1) {
> > > > > >-holes_size = max_addr - memblock_phys_mem_size();
> > > > > >-zholes_size[ZONE_DMA] = holes_size >> PAGE_SHIFT;
> > > > > >-}
> > > > > >+holes_size = max_addr - memblock_phys_mem_size();
> > > > > >+zholes_size[ZONE_DMA] = >> PAGE_SHIFT;
> > > > >
> > > > > gcc fails to parse that line. Lost a holes_size, perhaps?
> > > >
> > > > Oops, indeed.
> > >
> > > Thanks, we're getting progress. My system is booting again from hard
> > > drive
> > > with CONFIG_SINGLE_MEMORY_CHUNK=n.
> > > When booting from an initrd, it still crashes, see attached dmesg.
> >
> > The initrd memory is reserved after the memmap is allocated and the initrd
> > gets overwritten. Can you try this hack please:
>
> [...]
>
> Thanks, will try after my holidays.
>
> > > Hence still to fix:
> > > 1. Proper solution for CONFIG_SINGLE_MEMORY_CHUNK=y,
> > > 2. CONFIG_SINGLE_MEMORY_CHUNK=n and initrd.
> >
> > Even with those fixes I'm still concerned about the SECTION_SIZE_BITS and
> > MAX_PHYSMEM_BITS definitions.
> >
> > Without implementing vmemmap support we are limited in their maximal
> > difference by 8 bits. That means that either minimal section size would be
> > 16M or the maximal physical memory size would be limited to 1G. I'm not
> > that familiar with m68k machine variants to say if either of these
> > assumptions can be used.
>
> While an Amiga could, in theory, have ca. 3.8 GiB of RAM, in practice
> it's limited to 1 GiB, but most machines have only a fraction of that.
> AFAIK, other m68k machines are similar. So a limit of 1 GiB sounds fine
> to me.
>
> But what's the impact of the minimal section size? What does it really
> mean?
> As my A4000 has 12 MiB of RAM at 0x740, and that seems to work,
> it does not mean that address and size must be a multiple of 16 MiB?
>
> Memory configuration varies wildly among machines.
> IIRC, some Macs can have several discontiguous 1 MiB blocks.
Each section has a contiguous memory map for [section_start, section_end).
The section_start is SECTION_SIZE * section_nr.
The section_end is either SECTION_SIZE * (section_nr + 1) if the entire
section is populated or the end address of the memory chunk belonging to
that section.
For instance, with SECTION_SIZE of 16MiB your A4000 would have
section_start at 0x740 and section_end at 0x800.
If we were using, say, 8MiB sections, it would have two sections populated:
[0x740, 0x7c0), [0x7c0, 0x800].
The issue with having section size too big is that for machines that have
small chunks of discontiguous memory separated by less than SECTION_SIZE,
these chunks will map to the same section and this will cause creation of
unused memmap for the hole
Facts in the Singapore Political Context
Subject/Topic: Facts in the Singapore Political Context 13 JULY 2019 Saturday Singapore Time Article: Why Singapore voters are asking for Santas Claus as their ideal politician to challenge the ruling party Online Platform: The Online Citizen (TOC) Author: Terry Xu (Singaporean, Chief Editor of The Online Citizen) Date Published: 25 June 2019 URL: https://www.theonlinecitizen.com/2019/06/25/why-singapore-voters-are-asking-for-a-santas-claus-as-their-ideal-politician-to-challenge-the-ruling-party/ Excerpts from the above news article: "...we should set out the following facts in the Singapore political context. - Majority of Singaporeans will not fork out money to support political causes or parties for change (even if it is a change that they desire) - Most if not all Singapore businesses are beholden to the Government Linked Companies and those associated with it such as NTUC. - Singapore was ranked fourth on Economist’s crony-capitalism index in 2016. - Most Singaporeans will not stick their neck out for anyone penalised by the system. Forget what you know about the solidarity of citizens in Hong Kong, Taiwan or any other democratic country. (Notes: Mr. Turritopsis Dohrnii Teo En Ming is a 41-year old Singaporean Targeted Individual (TI) living in Singapore. After graduating from the National University of Singapore (NUS) 13 years ago in the year 2007, Mr. Teo En Ming did not have any stable job for the past 13 years. His employment history is extremely sparse for the past 13 years. In fact, he is not allowed to work for the past 13 years due to political pressure. In what subtle ways? He keeps getting fired or is forced to resign for the past 13 years due to political pressure. Many times he has to accept a job way under his specialization (university degree and computer networking diploma). His total Central Provident Fund (CPF) (CPF is a compulsory government "pension fund" which cannot be withdrawn) savings of SGD$56,969 (as at 27 Jun 2019) shows that he is extremely under-employed and under-achieved for the past 13 years as compared to his contemporaries. He has no career progression for the past 13 years, leading to stagnation or should I even say regression. He is always forced to accept an entry level/fresh university graduate salary of SGD$2800 (for IT professionals) or way lower (for mediocre jobs) for the past 13 years. His longest held job is only 12 months (1 year) in a small IT company in Singapore from Nov 2017 to Nov 2018. Compared to his contemporaries, Mr. Teo En Ming has the lowest Socio-Economic Status (SES) in Singapore and the poorest, even though he has a Bacheor's degree in Mechanical Engineering (with honors) from NUS, a diploma in Mechatronics Engineering (with Merit) from Singapore Polytechnic, and another diploma in Computer Networking (based on Cisco CCNA curriculum) from Singapore Polytechnic. What an irony! He lives in a HDB One-Room Rental Flat meant for the extremely poor in Singapore and he does not have any residential property, not even the most basic HDB 3-room flat. He has no car and not even a bicycle. Maybe he will also face difficulties buying toy cars as well. He has no credit cards at all for the past 13 years. Compared to other Singaporeans, he travels out of Singapore extremely infrequently due to a limited purse. Mr. Teo En Ming is an under-privileged Singaporean. He is a third class citizen in his own country. Maybe he is worse than third class. 1000th class??) - Most Singaporeans are grateful to the People’s Action Party for monetary handouts especially during election year even though the handouts are financed through the government and not the party. So what this essentially means – should the complaints of the average voters be valid – that an ideal political party or politician before considering its political ideology, should: - be able to self fund the party’s activities between elections because Singaporeans will not donate to political parties and neither will businesses because Prime Minister Office will be told who are the supporters." "Even the esteemed Dr Tan Cheng Bock will find it hard to please their standards as a running-candidate in the General Election for his party does not have the same war chest and the support from the business community as what his former political party has." "Most Singaporeans will not stick their neck out for anyone penalised by the system. Forget what you know about the solidarity of citizens in Hong Kong, Taiwan or any other democratic country." The following photos illustrate the stark contrast between a protest in Hong Kong and a protest in Singapore. [1] http://i67.tinypic.com/2lc63cw.png [2] https://i.imgur.com/nfOGSVT.png [3] https://i.postimg.cc/bJYLqn7p/HK-protest-vs-SG-protest.png -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link:
Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
On Fri, 12 Jul 2019, Geert Uytterhoeven wrote: > > Memory configuration varies wildly among machines. > IIRC, some Macs can have several discontiguous 1 MiB blocks. > Was that in the memory map provided by a bootloader running in MacOS in 24-bit addressing mode? I'm not sure that this actually works. --
Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
On Jul 12 2019, Geert Uytterhoeven wrote: > While an Amiga could, in theory, have ca. 3.8 GiB of RAM, in practice > it's limited to 1 GiB, but most machines have only a fraction of that. > AFAIK, other m68k machines are similar. So a limit of 1 GiB sounds fine > to me. That would severly limit the usefulness of emulators like Aranym. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
Hi Mike,
On Fri, Jul 5, 2019 at 9:25 PM Mike Rapoport wrote:
> On Mon, Jul 01, 2019 at 01:56:25PM +0200, Geert Uytterhoeven wrote:
> > On Sun, Jun 30, 2019 at 10:58 AM Mike Rapoport wrote:
> > > On Sun, Jun 30, 2019 at 12:54:49PM +1200, Michael Schmitz wrote:
> > > > Am 29.06.2019 um 23:30 schrieb Mike Rapoport:
> > > > >On Thu, Jun 20, 2019 at 06:46:28PM +0200, Geert Uytterhoeven wrote:
> > > > >>On Wed, Jun 19, 2019 at 4:18 PM Mike Rapoport
> > > > >>wrote:
> > > > >>>On Wed, Jun 19, 2019 at 09:39:40AM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Jun 19, 2019 at 9:06 AM Geert Uytterhoeven
> > > > wrote:
> > > > >On Tue, Jun 18, 2019 at 8:10 AM Mike Rapoport
> > > > >wrote:
> > > > >>
> > > > >>Thanks, that hack did fix CONFIG_SINGLE_MEMORY_CHUNK=y.
> > > > >>
> > > > >>Back to sparsemem...
> > > > >>
> > > > >>With CONFIG_SINGLE_MEMORY_CHUNK=n, and CONFIG_SPARSEMEM=y,
> > > > >>it also fails. Diff between working single memory chunk and failing
> > > > >>sparsemem:
> > > > >>
> > > > >> -Memory: 7796K/12288K available (2555K kernel code, 259K rwdata,
> > > > >>700K rodata, 136K init, 153K bss, 4492K reserved, 0K cma-reserved)
> > > > >> +Memory: 7816K/131072K available (2556K kernel code, 261K rwdata,
> > > > >>700K rodata, 136K init, 157K bss, 123256K reserved, 0K cma-reserved)
> > > > >>
> > > > >>Oops, looks like it thinks there's memory from 0x-0x0800,
> > > > >>instead of 0x0740-0x0800.
> > > > >
> > > > >Yeah, I've made a mistake in the zone/hole size calculations as it
> > > > >seems.
> > > > >
> > > > >Can you try this:
> > > > >
> > > > >diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
> > > > >index 87d09942be5c..bf438a0da173 100644
> > > > >--- a/arch/m68k/mm/motorola.c
> > > > >+++ b/arch/m68k/mm/motorola.c
> > > > >@@ -229,10 +229,8 @@ static void m68k_free_area_init(unsigned long
> > > > >max_addr)
> > > > > memblock_set_bottom_up(true);
> > > > >
> > > > > zones_size[ZONE_DMA] = max_addr >> PAGE_SHIFT;
> > > > >-if (m68k_num_memory > 1) {
> > > > >-holes_size = max_addr - memblock_phys_mem_size();
> > > > >-zholes_size[ZONE_DMA] = holes_size >> PAGE_SHIFT;
> > > > >-}
> > > > >+holes_size = max_addr - memblock_phys_mem_size();
> > > > >+zholes_size[ZONE_DMA] = >> PAGE_SHIFT;
> > > >
> > > > gcc fails to parse that line. Lost a holes_size, perhaps?
> > >
> > > Oops, indeed.
> >
> > Thanks, we're getting progress. My system is booting again from hard drive
> > with CONFIG_SINGLE_MEMORY_CHUNK=n.
> > When booting from an initrd, it still crashes, see attached dmesg.
>
> The initrd memory is reserved after the memmap is allocated and the initrd
> gets overwritten. Can you try this hack please:
[...]
Thanks, will try after my holidays.
> > Hence still to fix:
> > 1. Proper solution for CONFIG_SINGLE_MEMORY_CHUNK=y,
> > 2. CONFIG_SINGLE_MEMORY_CHUNK=n and initrd.
>
> Even with those fixes I'm still concerned about the SECTION_SIZE_BITS and
> MAX_PHYSMEM_BITS definitions.
>
> Without implementing vmemmap support we are limited in their maximal
> difference by 8 bits. That means that either minimal section size would be
> 16M or the maximal physical memory size would be limited to 1G. I'm not
> that familiar with m68k machine variants to say if either of these
> assumptions can be used.
While an Amiga could, in theory, have ca. 3.8 GiB of RAM, in practice
it's limited to 1 GiB, but most machines have only a fraction of that.
AFAIK, other m68k machines are similar. So a limit of 1 GiB sounds fine
to me.
But what's the impact of the minimal section size? What does it really
mean?
As my A4000 has 12 MiB of RAM at 0x740, and that seems to work,
it does not mean that address and size must be a multiple of 16 MiB?
Memory configuration varies wildly among machines.
IIRC, some Macs can have several discontiguous 1 MiB blocks.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
IsmaelinotS
Beste, U heeft ons onderstaand bericht verstuurd via de website: Uw naam: IsmaelinotS Uw onderwerp: IsmaelinotS Uw emailadres: linux-m...@lists.linux-m68k.org Uw bericht: Treffen Sie lokale Frauen, die heute Abend Sex auf XPress suchen: http://cort.as/-Kxjb?=yu4H8Sxye3i9w Wij helpen u zo snel mogelijk verder, HPB-service
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Joachim,
On 4/7/19 4:37 am, Joachim Dietrich wrote:
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a
wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3
The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.
coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this
was
the default handling for the mcf5329.
That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting
instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones
do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs.
OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15)
fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.
The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.
The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.
So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see arch/m68k/include/asm/m53xxacr.h).
Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?
OK. I will do that. But at first glance everything looks right (in the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.
Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.
The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.
Can you try the patch below?
I did it,
It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.
but for me it looks as if the patch has fixed only the described
problem, but the handling doesn't seem to work quite yet. But let me
explained this in more detail:
Without your patch, the kernel starts until the first user process. Let
this be a simple "Hello World", which prints the argv[0] and argv. In
this case usp points to a wrong address; the user process has no
arguments. No chance to start an init process.
With the new patch, the (same "Hello World") usp seems to points to a
correct address. The arguments are correct. So, I guess the EUSP Bit in
CACR is set.
But when I want to start the BusyBox init then I get a trap:
---
...
[2.78] This architecture does not have kernel memory protection.
[2.78] Run /sbin/init as init process
init started: BusyBox v1.29.3 (2019-06-04 13:30:06 CEST)
[3.31] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 01fa, exited with 01f9?
[3.32] softirq: huh, entered softirq 3 NET_RX (ptrval) with
Re: [PATCH v2 1/3] mmc: add Coldfire esdhc support
Hi Adrian, On Tue, Jul 02, 2019 at 12:10:54PM +0300, Adrian Hunter wrote: > On 20/06/19 1:22 AM, Angelo Dureghello wrote: > > Hi Christoph, > > > > On Sun, Jun 16, 2019 at 11:58:07PM -0700, Christoph Hellwig wrote: > >> On Sun, Jun 16, 2019 at 10:48:21PM +0200, Angelo Dureghello wrote: > >>> This driver has been developed as a separate module starting > >>> from the similar sdhci-esdhc-fls.c. > >>> Separation has been mainly driven from change in endianness. > >> > >> Can't we have a way to define the endianess at build or even runtime? > >> We have plenty of that elsewhere in the kernel. > > > > well, the base sdhci layer wants to access byte-size fields of the > > esdhc controller registers. > > But this same Freescale esdhc controller may be found in 2 > > flavors, big-endian or little-endian organized. > > So in this driver i am actually correcting byte-addresses to > > access the wanted byte-field in the big-endian hw controller. > > > > So this is a bit different from a be-le endian swap of a > > long or a short that the kernel is organized to do.. > > Did you consider just using different sdhci_ops so that you could support > different sdhci I/O accessors? Initially i tried to modify the IMX/Vybrid (arm) driver. But was stopped from several points, trying to remember now, - the I/O accessors was a const struct, but this of course is not a big issue, - here and there bitfields and positions of the ColdFire controller registers, compared to the arm versions, are different, so controller hw is not exactly the same, - on ColdFire controller and some behaviors and errata are different, - dma endiannes not hw-configurable, - ColdFire has max clock limitations, a bit different clock init. Finally, since there is already a common library (shdci.c) i decided to go as a separate driver, instead of filling the driver of "if (coldfire)" also mainly for the following reasons: 1) separated ColdFire driver has a quite small amount of code, simple to understand. 2) having drivers used by multiple architectures, it add risks, each time i perform a change, i can test it only on ColdFire, and can break the driver for the other architectures (i see this not rarely happening for multiple-arch used drivers). So let me know if the way chosen can be ok. Otherwise i will roll back trying to modify the iMX/Vybrid driver, likely adding a lot of "if (coldfire)" complicating it quite a lot. Regards, Angelo
Re: [PATCH v2 3/3] mmc: enabling ColdFire esdhc controller support
Hi Adrian, On Tue, Jul 02, 2019 at 12:11:02PM +0300, Adrian Hunter wrote: > On 16/06/19 11:48 PM, Angelo Dureghello wrote: > > Signed-off-by: Angelo Dureghello > > --- > > drivers/mmc/host/Kconfig | 13 + > > drivers/mmc/host/Makefile | 3 ++- > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > > index 931770f17087..9b426094d10a 100644 > > --- a/drivers/mmc/host/Kconfig > > +++ b/drivers/mmc/host/Kconfig > > @@ -221,6 +221,19 @@ config MMC_SDHCI_CNS3XXX > > > > If unsure, say N. > > > > +config MMC_SDHCI_ESDHC_MCF > > + tristate "SDHCI support for the Freescale eSDHC ColdFire controller" > > + depends on M5441x > > + depends on MMC_SDHCI_PLTFM > > + select MMC_SDHCI_IO_ACCESSORS > > + help > > + This selects the Freescale eSDHC controller support for > > + ColdFire mcf5441x devices. > > + > > + If you have a controller with this interface, say Y or M here. > > + > > + If unsure, say N. > > + > > config MMC_SDHCI_ESDHC_IMX > > tristate "SDHCI support for the Freescale eSDHC/uSDHC i.MX controller" > > depends on ARCH_MXC > > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile > > index 73578718f119..b2127ee5e71e 100644 > > --- a/drivers/mmc/host/Makefile > > +++ b/drivers/mmc/host/Makefile > > @@ -80,6 +80,7 @@ obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o > > obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o > > obj-$(CONFIG_MMC_SDHCI_CADENCE)+= sdhci-cadence.o > > obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o > > +obj-$(CONFIG_MMC_SDHCI_ESDHC_MCF) += sdhci-esdhc-mcf.o > > obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o > > obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o > > obj-$(CONFIG_MMC_SDHCI_TEGRA) += sdhci-tegra.o > > @@ -103,4 +104,4 @@ ifeq ($(CONFIG_CB710_DEBUG),y) > > endif > > > > obj-$(CONFIG_MMC_SDHCI_XENON) += sdhci-xenon-driver.o > > -sdhci-xenon-driver-y += sdhci-xenon.o sdhci-xenon-phy.o > > +sdhci-xenon-driver-y += sdhci-xenon.o sdhci-xenon-phy. > > Inadvertent change there Aaargh, sorry, good cactch :) Will fix it. Reagrds, Angelo
Re: [PATCH v2 2/3] mmc: sdhci: add quirks for be to le byte swapping
Hi Adrian,
thanks for the feedbacks.
On Tue, Jul 02, 2019 at 12:10:44PM +0300, Adrian Hunter wrote:
> On 16/06/19 11:48 PM, Angelo Dureghello wrote:
> > Some controller as the ColdFire eshdc may require an endianness
> > byte swap, because DMA read endianness is not configurable.
>
> I would prefer something more generic, like adding another callback
> for ->request_done() e.g.
>
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index f56ae6f153d4..a63e528cb885 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2729,7 +2729,10 @@ static bool sdhci_request_done(struct sdhci_host *host)
>
> spin_unlock_irqrestore(>lock, flags);
>
> - mmc_request_done(host->mmc, mrq);
> + if (host->ops->request_done)
> + host->ops->request_done(host, mrq);
> + else
> + mmc_request_done(host->mmc, mrq);
>
> return false;
> }
>
>
> Then you can use the ->request_done() callback to iterate over the data->sg
> and make byte-swaps as needed.
>
Ok, good to know, will try.
> >
> > Signed-off-by: Angelo Dureghello
> > ---
> > drivers/mmc/host/sdhci.c | 19 +++
> > drivers/mmc/host/sdhci.h | 7 +++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index 59acf8e3331e..f56ae6f153d4 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -2600,6 +2600,18 @@ static const struct mmc_host_ops sdhci_ops = {
> > .card_busy = sdhci_card_busy,
> > };
> >
> > +static void sdhci_be_to_le(char *buff, u32 length)
> > +{
> > + int i, size = length >> 2;
> > + u32 *buffer = (u32 *)buff;
> > + u32 temp;
> > +
> > + for (i = 0; i < size; i++) {
> > + temp = *buffer;
> > + *buffer++ = __le32_to_cpu(temp);
> > + }
> > +}
> > +
> >
> > /*\
> > *
> > *
> > * Request done
> > *
> > @@ -2655,6 +2667,13 @@ static bool sdhci_request_done(struct sdhci_host
> > *host)
> > host->bounce_addr,
> > host->bounce_buffer_size,
> > DMA_FROM_DEVICE);
> > +
> > + if (host->quirks2 &
> > + SDHCI_QUIRK2_USE_32BIT_BE_DMA_SWAP)
> > + sdhci_be_to_le(
> > + host->bounce_buffer,
> > + length);
> > +
> > sg_copy_from_buffer(data->sg,
> > data->sg_len,
> > host->bounce_buffer,
> > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> > index 199712e7adbb..be08ff1a8c6f 100644
> > --- a/drivers/mmc/host/sdhci.h
> > +++ b/drivers/mmc/host/sdhci.h
> > @@ -482,6 +482,13 @@ struct sdhci_host {
> > */
> > #define SDHCI_QUIRK2_USE_32BIT_BLK_CNT (1<<18)
> >
> > +/*
> > + * On some architectures, as ColdFire/m68k, native endianness is big
> > endian,
> > + * and the dma buffer is filled in big endian order only (no other
> > options).
> > + * So, a swap is needed for these specific cases.
> > + */
> > +#define SDHCI_QUIRK2_USE_32BIT_BE_DMA_SWAP (1<<19)
> > +
> > int irq;/* Device IRQ */
> > void __iomem *ioaddr; /* Mapped address */
> > char *bounce_buffer;/* For packing SDMA reads/writes */
> >
>
Reagrds,
Angelo
Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
On Mon, Jul 01, 2019 at 01:56:25PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Sun, Jun 30, 2019 at 10:58 AM Mike Rapoport wrote:
> > On Sun, Jun 30, 2019 at 12:54:49PM +1200, Michael Schmitz wrote:
> > > Am 29.06.2019 um 23:30 schrieb Mike Rapoport:
> > > >On Thu, Jun 20, 2019 at 06:46:28PM +0200, Geert Uytterhoeven wrote:
> > > >>On Wed, Jun 19, 2019 at 4:18 PM Mike Rapoport
> > > >>wrote:
> > > >>>On Wed, Jun 19, 2019 at 09:39:40AM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Jun 19, 2019 at 9:06 AM Geert Uytterhoeven
> > > wrote:
> > > >On Tue, Jun 18, 2019 at 8:10 AM Mike Rapoport
> > > >wrote:
> > > >>
> > > >>Thanks, that hack did fix CONFIG_SINGLE_MEMORY_CHUNK=y.
> > > >>
> > > >>Back to sparsemem...
> > > >>
> > > >>With CONFIG_SINGLE_MEMORY_CHUNK=n, and CONFIG_SPARSEMEM=y,
> > > >>it also fails. Diff between working single memory chunk and failing
> > > >>sparsemem:
> > > >>
> > > >> -Memory: 7796K/12288K available (2555K kernel code, 259K rwdata,
> > > >>700K rodata, 136K init, 153K bss, 4492K reserved, 0K cma-reserved)
> > > >> +Memory: 7816K/131072K available (2556K kernel code, 261K rwdata,
> > > >>700K rodata, 136K init, 157K bss, 123256K reserved, 0K cma-reserved)
> > > >>
> > > >>Oops, looks like it thinks there's memory from 0x-0x0800,
> > > >>instead of 0x0740-0x0800.
> > > >
> > > >Yeah, I've made a mistake in the zone/hole size calculations as it seems.
> > > >
> > > >Can you try this:
> > > >
> > > >diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
> > > >index 87d09942be5c..bf438a0da173 100644
> > > >--- a/arch/m68k/mm/motorola.c
> > > >+++ b/arch/m68k/mm/motorola.c
> > > >@@ -229,10 +229,8 @@ static void m68k_free_area_init(unsigned long
> > > >max_addr)
> > > > memblock_set_bottom_up(true);
> > > >
> > > > zones_size[ZONE_DMA] = max_addr >> PAGE_SHIFT;
> > > >-if (m68k_num_memory > 1) {
> > > >-holes_size = max_addr - memblock_phys_mem_size();
> > > >-zholes_size[ZONE_DMA] = holes_size >> PAGE_SHIFT;
> > > >-}
> > > >+holes_size = max_addr - memblock_phys_mem_size();
> > > >+zholes_size[ZONE_DMA] = >> PAGE_SHIFT;
> > >
> > > gcc fails to parse that line. Lost a holes_size, perhaps?
> >
> > Oops, indeed.
>
> Thanks, we're getting progress. My system is booting again from hard drive
> with CONFIG_SINGLE_MEMORY_CHUNK=n.
> When booting from an initrd, it still crashes, see attached dmesg.
The initrd memory is reserved after the memmap is allocated and the initrd
gets overwritten. Can you try this hack please:
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 528484feff80..eea111f25c3a 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -346,6 +346,13 @@ void __init setup_arch(char **cmdline_p)
panic("No configuration setup");
}
+#ifndef CONFIG_SUN3
+#ifdef CONFIG_BLK_DEV_INITRD
+ if (m68k_ramdisk.size)
+ memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
+#endif
+#endif
+
paging_init();
#ifdef CONFIG_NATFEAT
@@ -355,7 +362,6 @@ void __init setup_arch(char **cmdline_p)
#ifndef CONFIG_SUN3
#ifdef CONFIG_BLK_DEV_INITRD
if (m68k_ramdisk.size) {
- memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
initrd_end = initrd_start + m68k_ramdisk.size;
pr_info("initrd: %08lx - %08lx\n", initrd_start, initrd_end);
> Hence still to fix:
> 1. Proper solution for CONFIG_SINGLE_MEMORY_CHUNK=y,
> 2. CONFIG_SINGLE_MEMORY_CHUNK=n and initrd.
Even with those fixes I'm still concerned about the SECTION_SIZE_BITS and
MAX_PHYSMEM_BITS definitions.
Without implementing vmemmap support we are limited in their maximal
difference by 8 bits. That means that either minimal section size would be
16M or the maximal physical memory size would be limited to 1G. I'm not
that familiar with m68k machine variants to say if either of these
assumptions can be used.
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Sincerely yours,
Mike.
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Greg,
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a
wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3
The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.
coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this
was
the default handling for the mcf5329.
That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting
instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones
do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs.
OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15)
fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.
The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.
The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.
So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see arch/m68k/include/asm/m53xxacr.h).
Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?
OK. I will do that. But at first glance everything looks right (in the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.
Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.
The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.
Can you try the patch below?
I did it,
It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.
but for me it looks as if the patch has fixed only the described
problem, but the handling doesn't seem to work quite yet. But let me
explained this in more detail:
Without your patch, the kernel starts until the first user process. Let
this be a simple "Hello World", which prints the argv[0] and argv. In
this case usp points to a wrong address; the user process has no
arguments. No chance to start an init process.
With the new patch, the (same "Hello World") usp seems to points to a
correct address. The arguments are correct. So, I guess the EUSP Bit in
CACR is set.
But when I want to start the BusyBox init then I get a trap:
---
...
[2.78] This architecture does not have kernel memory protection.
[2.78] Run /sbin/init as init process
init started: BusyBox v1.29.3 (2019-06-04 13:30:06 CEST)
[3.31] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 01fa, exited with 01f9?
[3.32] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 0100, exited with 00f9?
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Joachim,
On 3/7/19 5:43 am, Joachim Dietrich wrote:
thank you for your explanations.
From: Joachim Dietrich
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3
The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.
coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this was
the default handling for the mcf5329.
That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs. OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15) fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.
The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.
The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.
So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see arch/m68k/include/asm/m53xxacr.h).
Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?
OK. I will do that. But at first glance everything looks right (in the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.
Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.
The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.
Can you try the patch below?
It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.
Regards
Greg
diff --git a/arch/m68k/include/asm/m53xxacr.h b/arch/m68k/include/asm/m53xxacr.h
index 9138a624c5c8..25b144495234 100644
--- a/arch/m68k/include/asm/m53xxacr.h
+++ b/arch/m68k/include/asm/m53xxacr.h
@@ -89,9 +89,9 @@
* coherency though in all cases. And for copyback caches we will need
* to push cached data as well.
*/
-#define CACHE_INIT CACR_CINVA
-#define CACHE_INVALIDATE CACR_CINVA
-#define CACHE_INVALIDATED CACR_CINVA
+#define CACHE_INIT(CACHE_MODE + CACR_CINVA)
+#define CACHE_INVALIDATE (CACHE_MODE + CACR_CINVA)
+#define CACHE_INVALIDATED (CACHE_MODE + CACR_CINVA)
#define ACR0_MODE ((CONFIG_RAMBASE & 0xff00) + \
(0x000f) + \
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Greg,
thank you for your explanations.
From: Joachim Dietrich
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3
The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.
coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this was
the default handling for the mcf5329.
That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs. OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15) fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.
The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.
The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.
So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see arch/m68k/include/asm/m53xxacr.h).
Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?
OK. I will do that. But at first glance everything looks right (in the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.
(*) I haven't checked the errata for the 5329, but I assume there
is no known bugs in the silicon in this area.
Thanks!
/joachim
Re: [PATCH 2/2] drivers/ata: convert pata_falcon to arch platform device
On 7/2/19 12:02 AM, Michael Schmitz wrote: > The Atari platform device setup now provides a platform device > for the Falcon IDE interface. Use this in place of the simple platform > device set up in the old pata_falcon probe code. > > Signed-off-by: Michael Schmitz Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics
Re: [PATCH 1/2] m68k/atari: add platform device for Falcon IDE port
On 7/2/19 12:02 AM, Michael Schmitz wrote: > Autoloading of Falcon IDE driver modules requires converting > these drivers to platform drivers. > > Add platform device for Falcon IDE interface in Atari platform > setup code in preparation for this. > > Signed-off-by: Michael Schmitz Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics
Re: [PATCH v2 3/3] mmc: enabling ColdFire esdhc controller support
On 16/06/19 11:48 PM, Angelo Dureghello wrote: > Signed-off-by: Angelo Dureghello > --- > drivers/mmc/host/Kconfig | 13 + > drivers/mmc/host/Makefile | 3 ++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index 931770f17087..9b426094d10a 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -221,6 +221,19 @@ config MMC_SDHCI_CNS3XXX > > If unsure, say N. > > +config MMC_SDHCI_ESDHC_MCF > + tristate "SDHCI support for the Freescale eSDHC ColdFire controller" > + depends on M5441x > + depends on MMC_SDHCI_PLTFM > + select MMC_SDHCI_IO_ACCESSORS > + help > + This selects the Freescale eSDHC controller support for > + ColdFire mcf5441x devices. > + > + If you have a controller with this interface, say Y or M here. > + > + If unsure, say N. > + > config MMC_SDHCI_ESDHC_IMX > tristate "SDHCI support for the Freescale eSDHC/uSDHC i.MX controller" > depends on ARCH_MXC > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile > index 73578718f119..b2127ee5e71e 100644 > --- a/drivers/mmc/host/Makefile > +++ b/drivers/mmc/host/Makefile > @@ -80,6 +80,7 @@ obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o > obj-$(CONFIG_MMC_SDHCI_PLTFM)+= sdhci-pltfm.o > obj-$(CONFIG_MMC_SDHCI_CADENCE) += sdhci-cadence.o > obj-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o > +obj-$(CONFIG_MMC_SDHCI_ESDHC_MCF) += sdhci-esdhc-mcf.o > obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX)+= sdhci-esdhc-imx.o > obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o > obj-$(CONFIG_MMC_SDHCI_TEGRA)+= sdhci-tegra.o > @@ -103,4 +104,4 @@ ifeq ($(CONFIG_CB710_DEBUG),y) > endif > > obj-$(CONFIG_MMC_SDHCI_XENON)+= sdhci-xenon-driver.o > -sdhci-xenon-driver-y += sdhci-xenon.o sdhci-xenon-phy.o > +sdhci-xenon-driver-y += sdhci-xenon.o sdhci-xenon-phy. Inadvertent change there
Re: [PATCH v2 2/3] mmc: sdhci: add quirks for be to le byte swapping
On 16/06/19 11:48 PM, Angelo Dureghello wrote:
> Some controller as the ColdFire eshdc may require an endianness
> byte swap, because DMA read endianness is not configurable.
I would prefer something more generic, like adding another callback
for ->request_done() e.g.
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f56ae6f153d4..a63e528cb885 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2729,7 +2729,10 @@ static bool sdhci_request_done(struct sdhci_host *host)
spin_unlock_irqrestore(>lock, flags);
- mmc_request_done(host->mmc, mrq);
+ if (host->ops->request_done)
+ host->ops->request_done(host, mrq);
+ else
+ mmc_request_done(host->mmc, mrq);
return false;
}
Then you can use the ->request_done() callback to iterate over the data->sg
and make byte-swaps as needed.
>
> Signed-off-by: Angelo Dureghello
> ---
> drivers/mmc/host/sdhci.c | 19 +++
> drivers/mmc/host/sdhci.h | 7 +++
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 59acf8e3331e..f56ae6f153d4 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2600,6 +2600,18 @@ static const struct mmc_host_ops sdhci_ops = {
> .card_busy = sdhci_card_busy,
> };
>
> +static void sdhci_be_to_le(char *buff, u32 length)
> +{
> + int i, size = length >> 2;
> + u32 *buffer = (u32 *)buff;
> + u32 temp;
> +
> + for (i = 0; i < size; i++) {
> + temp = *buffer;
> + *buffer++ = __le32_to_cpu(temp);
> + }
> +}
> +
>
> /*\
> *
> *
> * Request done
> *
> @@ -2655,6 +2667,13 @@ static bool sdhci_request_done(struct sdhci_host *host)
> host->bounce_addr,
> host->bounce_buffer_size,
> DMA_FROM_DEVICE);
> +
> + if (host->quirks2 &
> + SDHCI_QUIRK2_USE_32BIT_BE_DMA_SWAP)
> + sdhci_be_to_le(
> + host->bounce_buffer,
> + length);
> +
> sg_copy_from_buffer(data->sg,
> data->sg_len,
> host->bounce_buffer,
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 199712e7adbb..be08ff1a8c6f 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -482,6 +482,13 @@ struct sdhci_host {
> */
> #define SDHCI_QUIRK2_USE_32BIT_BLK_CNT (1<<18)
>
> +/*
> + * On some architectures, as ColdFire/m68k, native endianness is big endian,
> + * and the dma buffer is filled in big endian order only (no other options).
> + * So, a swap is needed for these specific cases.
> + */
> +#define SDHCI_QUIRK2_USE_32BIT_BE_DMA_SWAP (1<<19)
> +
> int irq;/* Device IRQ */
> void __iomem *ioaddr; /* Mapped address */
> char *bounce_buffer;/* For packing SDMA reads/writes */
>
Re: [PATCH v2 1/3] mmc: add Coldfire esdhc support
On 20/06/19 1:22 AM, Angelo Dureghello wrote: > Hi Christoph, > > On Sun, Jun 16, 2019 at 11:58:07PM -0700, Christoph Hellwig wrote: >> On Sun, Jun 16, 2019 at 10:48:21PM +0200, Angelo Dureghello wrote: >>> This driver has been developed as a separate module starting >>> from the similar sdhci-esdhc-fls.c. >>> Separation has been mainly driven from change in endianness. >> >> Can't we have a way to define the endianess at build or even runtime? >> We have plenty of that elsewhere in the kernel. > > well, the base sdhci layer wants to access byte-size fields of the > esdhc controller registers. > But this same Freescale esdhc controller may be found in 2 > flavors, big-endian or little-endian organized. > So in this driver i am actually correcting byte-addresses to > access the wanted byte-field in the big-endian hw controller. > > So this is a bit different from a be-le endian swap of a > long or a short that the kernel is organized to do.. Did you consider just using different sdhci_ops so that you could support different sdhci I/O accessors?
Motorola 68000 series (Wikipedia)
Good afternoon from Singapore, Article: Motorola 68000 series (Wikipedia) Link: https://en.wikipedia.org/wiki/Motorola_68000_series Thank you. -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Joachim,
On 2/7/19 4:49 am, Joachim Dietrich wrote:
let me add a few remarks.
From: Joachim Dietrich
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3
The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.
coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this was
the default handling for the mcf5329.
That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs. OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15) fails at
rdusp() and wdusp() in processor.h and my first user process has a wrong sp.
The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.
The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.
So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see arch/m68k/include/asm/m53xxacr.h).
Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?
(*) I haven't checked the errata for the 5329, but I assume there
is no known bugs in the silicon in this area.
Regards
Greg
Thanks!
[1] https://www.nxp.com/docs/en/reference-manual/MCF5329RM.pdf
[2] https://www.nxp.com/docs/en/data-sheet/MCF5206UM.pdf
---
arch/m68k/Kconfig.cpu | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 60ac1cd8b96fb868..e41e74cd1125b8de 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -239,6 +239,7 @@ config M532x
depends on !MMU
select M53xx
select HAVE_CACHE_CB
+ select COLDFIRE_SW_A7
help
Freescale (Motorola) ColdFire 532x processor support.
Thanks!
/joachim
[PATCH 1/2] m68k/atari: add platform device for Falcon IDE port
Autoloading of Falcon IDE driver modules requires converting
these drivers to platform drivers.
Add platform device for Falcon IDE interface in Atari platform
setup code in preparation for this.
Signed-off-by: Michael Schmitz
--
Changes from RFC
- fix region size (spotted by Szymon Bieganski )
- define IDE interface address in atari/config.c, create platform device
always (suggested by Geert Uytterhoeven )
---
arch/m68k/atari/config.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/atari/config.c b/arch/m68k/atari/config.c
index ca8469e..c10533c 100644
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -896,6 +896,25 @@ static void isp1160_delay(struct device *dev, int delay)
};
#endif
+/*
+ * Falcon IDE interface
+ */
+
+#define FALCON_IDE_BASE0xfff0
+
+static const struct resource atari_falconide_rsrc[] __initconst = {
+ {
+ .flags = IORESOURCE_MEM,
+ .start = FALCON_IDE_BASE,
+ .end = FALCON_IDE_BASE+0x39,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = IRQ_MFP_FSCSI,
+ .end = IRQ_MFP_FSCSI,
+ },
+};
+
int __init atari_platform_init(void)
{
int rv = 0;
@@ -939,6 +958,10 @@ int __init atari_platform_init(void)
atari_scsi_tt_rsrc, ARRAY_SIZE(atari_scsi_tt_rsrc));
#endif
+ if (ATARIHW_PRESENT(IDE))
+ platform_device_register_simple("pata_falcon", -1,
+ atari_falconide_rsrc, ARRAY_SIZE(atari_falconide_rsrc));
+
return rv;
}
--
1.7.0.4
[PATCH 2/2] drivers/ata: convert pata_falcon to arch platform device
The Atari platform device setup now provides a platform device
for the Falcon IDE interface. Use this in place of the simple platform
device set up in the old pata_falcon probe code.
Signed-off-by: Michael Schmitz
---
drivers/ata/pata_falcon.c | 39 +++
1 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/ata/pata_falcon.c b/drivers/ata/pata_falcon.c
index 41e0d6a..1ff6fcb 100644
--- a/drivers/ata/pata_falcon.c
+++ b/drivers/ata/pata_falcon.c
@@ -120,23 +120,21 @@ static int pata_falcon_set_mode(struct ata_link *link,
.set_mode = pata_falcon_set_mode,
};
-static int pata_falcon_init_one(void)
+static int __init pata_falcon_init_one(struct platform_device *pdev)
{
+ struct resource *res;
struct ata_host *host;
struct ata_port *ap;
- struct platform_device *pdev;
void __iomem *base;
- if (!MACH_IS_ATARI || !ATARIHW_PRESENT(IDE))
- return -ENODEV;
-
- pr_info(DRV_NAME ": Atari Falcon PATA controller\n");
+ dev_info(>dev, ": Atari Falcon PATA controller\n");
- pdev = platform_device_register_simple(DRV_NAME, 0, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
- if (!devm_request_mem_region(>dev, ATA_HD_BASE, 0x40, DRV_NAME)) {
+ if (!devm_request_mem_region(>dev, res->start,
+resource_size(res), DRV_NAME)) {
pr_err(DRV_NAME ": resources busy\n");
return -EBUSY;
}
@@ -152,7 +150,7 @@ static int pata_falcon_init_one(void)
ap->flags |= ATA_FLAG_SLAVE_POSS | ATA_FLAG_NO_IORDY;
ap->flags |= ATA_FLAG_PIO_POLLING;
- base = (void __iomem *)ATA_HD_BASE;
+ base = (void __iomem *)res->start;
ap->ioaddr.data_addr= base;
ap->ioaddr.error_addr = base + 1 + 1 * 4;
ap->ioaddr.feature_addr = base + 1 + 1 * 4;
@@ -174,9 +172,26 @@ static int pata_falcon_init_one(void)
return ata_host_activate(host, 0, NULL, 0, _falcon_sht);
}
-module_init(pata_falcon_init_one);
+static int __exit pata_falcon_remove_one(struct platform_device *pdev)
+{
+ struct ata_host *host = platform_get_drvdata(pdev);
+
+ ata_host_detach(host);
+
+ return 0;
+}
+
+static struct platform_driver pata_falcon_driver = {
+ .remove = __exit_p(pata_falcon_remove_one),
+ .driver = {
+ .name = "atari-falcon-ide",
+ },
+};
+
+module_platform_driver_probe(pata_falcon_driver, pata_falcon_init_one);
MODULE_AUTHOR("Bartlomiej Zolnierkiewicz");
MODULE_DESCRIPTION("low-level driver for Atari Falcon PATA");
MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:atari-falcon-ide");
MODULE_VERSION(DRV_VERSION);
--
1.7.0.4
[PATCH 0/2] Convert Atari Falcon IDE driver to platform device
As suggested by Geert, at least one of the drivers available for the Falcon IDE interface should be converted to a platform device driver (to enable module autoloading by the Debian installer). Add platform device for Falcon IDE (patch 1), and rewrite the present libata driver to make use of that device (patch 2). Tested on ARAnyM with driver builtin. Cheers, Michael
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
On Jul 01 2019, Joachim Dietrich wrote: > coldfire, because in the reference manual of the mcf5329 stands: "To > support dual stack pointers, the following two supervisor instructions > are included in the ColdFire instruction set architecture to load/store > the USP: > move.l Ay,USP;move to USP > move.l USP,Ax;move from USP" Thus from the software point of view the classic m68k view of the USP is compatible with the coldfire V3. The OTHER_A7 designation is only visible via the BDM. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
Hi Greg,
let me add a few remarks.
From: Joachim Dietrich
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.
Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3
coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this was
the default handling for the mcf5329.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs. OTHER_A7?
Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15) fails at
rdusp() and wdusp() in processor.h and my first user process has a wrong sp.
Thanks!
[1] https://www.nxp.com/docs/en/reference-manual/MCF5329RM.pdf
[2] https://www.nxp.com/docs/en/data-sheet/MCF5206UM.pdf
---
arch/m68k/Kconfig.cpu | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 60ac1cd8b96fb868..e41e74cd1125b8de 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -239,6 +239,7 @@ config M532x
depends on !MMU
select M53xx
select HAVE_CACHE_CB
+ select COLDFIRE_SW_A7
help
Freescale (Motorola) ColdFire 532x processor support.
Thanks!
/joachim
[PATCH] m68knommu: Add SW_A7 support to mcf5329
From: Joachim Dietrich
There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a wrong
stack pointer.
Signed-off-by: Joachim Dietrich
Signed-off-by: Geert Uytterhoeven
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling. According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.
Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.
It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs. OTHER_A7?
Thanks!
[1] https://www.nxp.com/docs/en/reference-manual/MCF5329RM.pdf
[2] https://www.nxp.com/docs/en/data-sheet/MCF5206UM.pdf
---
arch/m68k/Kconfig.cpu | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 60ac1cd8b96fb868..e41e74cd1125b8de 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -239,6 +239,7 @@ config M532x
depends on !MMU
select M53xx
select HAVE_CACHE_CB
+ select COLDFIRE_SW_A7
help
Freescale (Motorola) ColdFire 532x processor support.
--
2.17.1
