linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bryan O'Donoghue" <pure.logic@nexus-software.ie>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, dvhart@infradead.org,
	platform-driver-x86@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000
Date: Thu, 01 Jan 2015 20:11:10 +0000	[thread overview]
Message-ID: <54A5A9DE.5060006@nexus-software.ie> (raw)
In-Reply-To: <CAHp75VeYg1oAp5x9OCKOyZGvkt9n4WBRuWV4QPBHbrq+vTzANg@mail.gmail.com>

On 31/12/14 15:05, Andy Shevchenko wrote:

<snip>
>> +int imr_del(int reg, unsigned long base, unsigned long size);
>
> Same comments as for add_range.
> Could it be imr_remove_range() ?

Can be. You've actually caught me out there, function name is "imr_del"
function description says imr_del_range(). Amazing to think I proof read
this file a number of times for exactly thing type of thing

I'm happy with

imr_add_range();
imr_remove_range();

>> +
>> +#endif /* _IMR_H */
>> diff --git a/arch/x86/include/asm/intel-quark.h
b/arch/x86/include/asm/intel-quark.h
>> new file mode 100644
>> index 0000000..f51ac8c
>> --- /dev/null
>> +++ b/arch/x86/include/asm/intel-quark.h

<snip>

>> +#ifdef CONFIG_X86_32
>> +static inline int cpu_is_quark(const struct cpuinfo_x86 *c)
>> +{
>> +       return (c->x86_vendor == X86_VENDOR_INTEL &&
>> +               c->x86 == 5 && c->x86_model == 9);
>> +}
>> +#else
>> +static inline int cpu_is_quark(const struct cpuinfo_x86 *c)
>> +{
>> +       return 0;
>> +}
>> +#endif
>> +
>> +#endif /* _ASM_X86_INTEL_QUARK_H */
>
> Could we use x86_match_cpu() instead?

I don't see why not. I'll kill this header and call out to
x86_match_cpu() in the Galileo and IMR code.

>> +       ret = iosf_mbi_read(QRK_MBI_UNIT_MM, QRK_MBI_MM_READ,
>> +                               reg, &imr->addr_lo);
>> +       if (ret)
>> +               return ret;
>> +
>> +       ret = iosf_mbi_read(QRK_MBI_UNIT_MM, QRK_MBI_MM_READ,
>> +                               ++reg, &imr->addr_hi);
>
> Could you use reg++ in previous line and so on?

Yes I could. Originally wrote the code with a pre-increment and then
changed the flow later on. Post-increment will work just as good now and
is more readable.

> One more idea, if you make a union inside the structure you may do
> this in a loop.
> struct imr {
>  union {
>   struct imr {
>  ...
>   };
>   u32 regs[IMR_NUM_REGS];
>  };
> }
> Mostly same for _write().

Since reg is incrementing on each iosf_mbi_dothing() that can work.

>> +       u32 reg = imr_dev.reg_base + (imr_id * IMR_NUM_REGS);
>> +       u32 reg_lock = reg;
>
> Do we need a separate variable? Would (reg - IMR_NUM_REGS) work for you?

Sure. A separate integer isn't required, I can make that change.

>> +done:
>> +       local_irq_restore(flags);
>
> Could you do like
>
>       local_irq_restore(flags);
>       return 0;
> done:
>       local_irq_restore(flags);
>       WARN(...)
>      return ret;
> ?

Doesn't change the logic so yeah, works for me.

>> +static int imr_dbgfs_state_show(struct seq_file *s, void *unused)
>> +{
>> +       int i, ret = -ENODEV;
>> +       struct imr imr;
>> +       u32 size;
>> +
>> +       mutex_lock(&imr_dev.lock);
>
> It seems you may get the imr_dev via parameters. I suggest to avoid
> using global variables as much as possible.

Appreciated, you're right globals are bad.

I think in this case the mutex at that scope is necessary though. Same
with the debugfs handle.

>> +
>> +       for (i = 0; i <= imr_dev.num; i++) {
>
> num is not num, but last one? Sounds confusing for me.

Will change.

>> +
>> +       f = debugfs_create_file("state", S_IFREG | S_IRUGO,
>> +                               dir, imr_dev, &imr_state_ops);
>> +       if (!f)
>> +               goto err;
>
> Are you planing to extend the debugfs contents? Would it be okay to
> use only one file for now?

No not planning to extend.
OK with the one file.

>> +}
>
> No need to put this function under ifdef  - debugfs has the stubs.

Ah - wasn't aware of that.
Great stuff - I'll kill the ifdefs - thanks !

> Can you define pr_fmt() ?
>
> 1 KiB.

Yep will do
:g/pr_info/s//pr_fmt/g

>
>> +                       base, size);
>> +               dump_stack();
>
> dump_stack is really needed here? In that case why not to use WARN()?

Hmm - I nope - dump_stack() isn't relevant since it's an in-kernel API.
Did an unthinking copy/past from the mtrr code

I'll zap that.

>> +       if (imr_check_range(base, size))
>> +               return -EINVAL;
>
> ret = imr_();
> if (ret)
>  return ret;

Good catch.

>> +       for (i = 0; i <= imr_dev.num; i++) {
>> +               ret = imr_read(i, &imr);
>> +               if (ret)
>> +                       goto done;
>> +
>> +               /* Find overlap */
>> +               if (imr_enabled(&imr)) {
>> +                       if (base >= imr_to_phys(imr.addr_lo) &&
>> +                               base <= imr_to_phys(imr.addr_hi)) {
>
>> +                               overlap = 1;
>> +                               break;
>
> Maybe
> ret = -EINVAL;
> goto done;

Agree - I like that change.
Waste of time to complete the loop if an overlap is detected.


>> +       if (reg >= 0) {
>> +               ret = imr_read(reg, &imr);
>> +               if (ret)
>> +                       goto done;
>> +
>> +               if (!imr_enabled(&imr) || imr.addr_lo & IMR_LOCK) {
>> +                       ret = -ENODEV;
>> +                       goto done;
>> +               }
>> +               found = 1;
>
> You may put a loop to the else branch instead of checking found at
> each iteration.

Sure.

> Happy New Year!

Thanks for the feedback Andy !
Best wishes in the New Year.

BOD



  reply	other threads:[~2015-01-01 20:11 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-29 17:23 [PATCH 0/2] x86: Add IMR support to Quark/Galileo Bryan O'Donoghue
2014-12-29 17:23 ` [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000 Bryan O'Donoghue
2014-12-31 15:05   ` Andy Shevchenko
2015-01-01 20:11     ` Bryan O'Donoghue [this message]
2015-01-06  7:36   ` Darren Hart
2015-01-06 13:43     ` Bryan O'Donoghue
2015-01-06 16:54       ` Darren Hart
2015-01-07 23:45       ` Ong, Boon Leong
2015-01-08 12:10         ` Bryan O'Donoghue
2015-01-08 14:52           ` Ong, Boon Leong
2015-01-08  0:04   ` Ong, Boon Leong
2015-01-08 13:08     ` Bryan O'Donoghue
2015-01-08 14:45       ` Ong, Boon Leong
2015-01-08 15:11         ` Bryan O'Donoghue
2015-01-09  3:44           ` Darren Hart
2014-12-29 17:23 ` [PATCH 2/2] platform/x86: Add Intel Galileo platform specific setup Bryan O'Donoghue
2014-12-31 15:25   ` Andy Shevchenko
2015-01-09  1:00   ` Ong, Boon Leong
2015-01-09  2:11     ` Bryan O'Donoghue
2015-01-09  4:46   ` Darren Hart
2015-01-09 11:17     ` Bryan O'Donoghue
2015-01-09 11:29       ` Bryan O'Donoghue
2015-01-09 14:11         ` Ong, Boon Leong
2015-01-10  6:54       ` Darren Hart
2015-01-11  1:53         ` Bryan O'Donoghue
2014-12-31 10:12 ` [PATCH 0/2] x86: Add IMR support to Quark/Galileo Andy Shevchenko
2014-12-31 11:59   ` Bryan O'Donoghue
2015-01-02  2:02   ` Darren Hart
2015-01-02  4:24 ` Darren Hart
2015-01-06  6:00 ` Darren Hart
2015-01-06 13:56   ` Bryan O'Donoghue
2015-01-06 16:48     ` Darren Hart
2015-01-06 17:23       ` Bryan O'Donoghue
2015-01-28 18:36 [PATCH v6 " Bryan O'Donoghue
2015-01-28 18:36 ` [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000 Bryan O'Donoghue
2015-01-29  5:38   ` Darren Hart
2015-01-29  7:44   ` Ingo Molnar
2015-01-29 10:08     ` Andy Shevchenko
2015-01-29 10:12       ` Bryan O'Donoghue
2015-01-29 13:47         ` Ong, Boon Leong
2015-01-29 15:22           ` Bryan O'Donoghue
2015-01-29 15:32             ` Ong, Boon Leong
2015-01-29 15:40               ` Bryan O'Donoghue
2015-01-29 16:12                 ` Bryan O'Donoghue
2015-01-29 16:26                   ` Ong, Boon Leong
2015-01-29 15:15         ` Ong, Boon Leong
2015-01-29 13:27     ` Bryan O'Donoghue
2015-01-29  9:59   ` Ong, Boon Leong

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=54A5A9DE.5060006@nexus-software.ie \
    --to=pure.logic@nexus-software.ie \
    --cc=andy.shevchenko@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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).