linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Oliver O'Halloran" <oohall@gmail.com>
To: schindele@nentec.de
Cc: Scott Wood <oss@buserror.net>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] Freescale mpc8315 interrupt chip
Date: Thu, 11 May 2017 23:38:24 +1000	[thread overview]
Message-ID: <CAOSf1CE6hvRD1Q_TXzdGoCRsGxq2yYLiunTGaFKbvx1rhAwbcw@mail.gmail.com> (raw)
In-Reply-To: <3052456.ktpuaNmngy@sherry>

On Thu, May 11, 2017 at 10:34 PM, Juergen Schindele <schindele@nentec.de> wrote:
> Next try to submit two patches for Freescale mpc8315.
>
> first one
> -----------------------------------------------------------------------------------
> powerpc/ipic: Configure "EDGE" capabilities for IRQ0 too (like IRQ1-7)
> Signed-off-by: Jurgen Schindele <schindele@nentec.de>
>
> The external IRQ0 has the same capabilities as the other IRQ1-7 and is
> handeled by the same register IPIC_SEPNR. When this register for "ack"
> is not setup in "ipic_info" you can not configure this IRQ for
> IRQ_TYPE_EDGE_FALLING. This is probably due to the non-continued number
> of IRQ0 in the Freescale hwirq number mapping.
>
> --- linux-4.11/arch/powerpc/sysdev/ipic.c.orig  2017-05-11 13:40:43.874801534
> +0200
> +++ linux-4.11/arch/powerpc/sysdev/ipic.c       2017-05-11 14:05:06.336610289
> +0200
> @@ -315,6 +315,7 @@ static struct ipic_info ipic_info[] = {
>                 .prio_mask = 7,
>         },
>         [48] = {
> +               .ack    = IPIC_SEPNR,
>                 .mask   = IPIC_SEMSR,
>                 .prio   = IPIC_SMPRR_A,
>                 .force  = IPIC_SEFCR,
>
> second one
> -----------------------------------------------------------------------------------------

> powerpc/ipic: Precise ERR printk when "ipic_set_irq_type" fails
> Signed-off-by: Jurgen Schindele <schindele@nentec.de>

The Signed-off-by: goes after the commit message. So rather than being here:
| >
| > When you setup an interrupt of a certain type on this interrupt-controler
| > which is not supported on this hardware you will get an error log but you
| > dont know which interrupt was the cause.
| > With this patch you are able to localize the source of failure.
|
\---> you want it down here

>
> --- linux-4.11/arch/powerpc/sysdev/ipic.c.orig  2017-05-11 14:08:07.098824986
> +0200
> +++ linux-4.11/arch/powerpc/sysdev/ipic.c       2017-05-11 14:10:51.010934755
> +0200
> @@ -611,14 +611,14 @@ static int ipic_set_irq_type(struct irq_
>         /* ipic supports only low assertion and high-to-low change senses
>          */
>         if (!(flow_type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_FALLING))) {
> -               printk(KERN_ERR "ipic: sense type 0x%x not supported\n",
> -                       flow_type);
> +               printk(KERN_ERR "ipic: sense type 0x%x not supported on "
> +                       "interrupt %d\n", flow_type, src);
>                 return -EINVAL;
>         }
>         /* ipic supports only edge mode on external interrupts */
>         if ((flow_type & IRQ_TYPE_EDGE_FALLING) && !ipic_info[src].ack) {
>                 printk(KERN_ERR "ipic: edge sense not supported on internal "
> -                               "interrupts\n");
> +                               "interrupt %d\n", src);

While you're here might as well change these from the old style
"printk(KERN_ERR" to the new style "pr_err()"

>                 return -EINVAL;
>
>         }
>

> I hope i respected all patch requirements ;-)

It's an interesting take on the rules, but it needs a bit of work.
We're pedantic about patch formatting, etc because we have tools for
handling patches that require strict formatting in order to function
(e.g https://patchwork.ozlabs.org/project/linuxppc-dev/list/). The
easiest way to ensure you get the formatting right is to use git to
generate the patch files for you, so:

First of all grab a kernel git tree (warning: it's big):
$ git clone https://github.com/torvalds/linux.git

Once it's done, make your changes inside of the git tree. You can run
"git diff" to get a diff between what has been commited in the tree
and what's in the filesystem. To start turning your changes into
patches use:
$ git add -p

NB: you can see what's been staged so fair with:
 $ git diff --staged

When you're happy with the staged changes commit them with:
$ git commit

This will give you a text editor where you can enter the commit
message. You can skip the signed-off-by for now. You'll probably get
yelled at by git for not having a name or an email. You should do what
it says to set those up so your name appears correctly in the patch.

Once you've done all that you should see two commits in:
$ git log

To finish generate the actual patch files with:
$ git format-patch -s HEAD~2

You can (in theory) use any email client to send patches. In practice
most clients are bad at handling whitespace and will do things like
turn tabs into spaces which breaks the diffs. The easiest way get it
right is to use git's email sending plugin. send-email isn't part of
the standard git package so you'll probably need to install and
configure it to use your local SMTP server. It's well worth the hassle
though.
$ git send-email --to=linuxppc-dev@lists.ozlabs.org <patch files go here>

Hope all that helps. There are much better git tutorials out there
than some idiot of the linuxppc-dev mailing list, but that should be
enough to get you started.
Oliver

      reply	other threads:[~2017-05-11 13:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10 14:53 Freescale mpc8315 IRQ0 setup Juergen Schindele
2017-04-30  6:55 ` Scott Wood
2017-05-02 12:43   ` Juergen Schindele
2017-05-03  3:29     ` Scott Wood
2017-05-04 15:06       ` Juergen Schindele
2017-05-04 20:55         ` Scott Wood
2017-05-11 12:34           ` [PATCH] Freescale mpc8315 interrupt chip Juergen Schindele
2017-05-11 13:38             ` Oliver O'Halloran [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOSf1CE6hvRD1Q_TXzdGoCRsGxq2yYLiunTGaFKbvx1rhAwbcw@mail.gmail.com \
    --to=oohall@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=oss@buserror.net \
    --cc=schindele@nentec.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).