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
next prev parent 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).