From: Boaz Harrosh <boaz@plexistor.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Ingo Molnar <mingo@redhat.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
X86 ML <x86@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Roger C. Pao" <rcpao.enmotus@gmail.com>,
Dan Williams <dan.j.williams@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-nvdimm <linux-nvdimm@ml01.01.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Matthew Wilcox <willy@linux.intel.com>,
Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH 2/3] resource: Add new flag IORESOURCE_WARN (64bit)
Date: Tue, 24 Feb 2015 09:20:14 +0200 [thread overview]
Message-ID: <54EC262E.9010903@plexistor.com> (raw)
In-Reply-To: <CALCETrXBwJdAarXVgO7VaEkTHtnO=-+n7mXy02PbS+sLqNiMyA@mail.gmail.com>
On 02/23/2015 05:46 PM, Andy Lutomirski wrote:
> On Mon, Feb 23, 2015 at 4:43 AM, Boaz Harrosh <boaz@plexistor.com> wrote:
>>
>> Resource providers set this flag if they want
>> that request_region_XXX will print a warning in dmesg
>> if this particular resource is locked by a driver.
>>
>> Thous acting as a Protocol Police about experimental
>> devices that did not pass a comity approval.
>>
>> The warn print looks like this:
>> [Feb22 19:59] resource: request unknown region [mem 0x100000000-0x1ffffffff] unkown-12
>> Where the unkown-12 is taken from the res->name
>>
>> The Only user of this flag is x86/kernel/e820.c that
>> wants to WARN about UNKNOWN memory types.
>>
>> NOTE: This patch looks very simple, a bit flag
>> communicates between a resource provider ie e820.c
>> that a warning should be printed, and resource.c
>> prints such a message, when the resource is locked
>> for use.
>
> I'm not really convinced this is necessary. If you somehow manage to
> reserve a physical address corresponding to an nvdimm, you probably
> know what you're doing.
I think so too but, Ingo asked for it and I understand how it can be
useful
> After all, no in-tree driver will do this by
> default.
What? why? I intend to send pmem upstream soon. For god's sake
These devices are out there, lots of them, used everyday, since
when do we keep people systems out-of-tree?
And why because some comity did not anticipate that the DDR bus
will be used for "something else". With PCI or any other bus
I develop a new card, give it an ID, scan for it and use it.
DDR no, I need to re-write my BIOS, god. I wish it was Linux
that was scanning the DDR bus, who gives a *ck about BIOS.
I thought it was you who pushed for Linux's scan of the DDR bus?
DDR bus will be used for lots more then flat NvDIMM, we will see
soon, and already see, lots of Devices off of the DDR bus which as
nothing to do with memory. The BIOS and e820 better be put aside,
we need a simple scan and ID for these devices and let upper drivers
take care of them. What do you want to happen, that each new device
needs to go through this ordeal all over again?
>
> --Andy
>
Free life
Boaz
next prev parent reply other threads:[~2015-02-24 7:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 12:29 [PATCH 0/3 v2] e820: Fix handling of NvDIMM chips Boaz Harrosh
2015-02-23 12:33 ` [PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY Boaz Harrosh
2015-02-24 4:22 ` Dan Williams
2015-02-24 7:59 ` Boaz Harrosh
2015-02-24 8:34 ` Ingo Molnar
2015-02-24 8:51 ` Boaz Harrosh
2015-02-26 2:09 ` Dan Williams
2015-02-23 12:43 ` [PATCH 2/3] resource: Add new flag IORESOURCE_WARN (64bit) Boaz Harrosh
2015-02-23 15:46 ` Andy Lutomirski
2015-02-24 7:20 ` Boaz Harrosh [this message]
2015-02-24 19:58 ` Andy Lutomirski
2015-02-24 8:39 ` [PATCH 2/3 v3] resource: Add new flag IORESOURCE_MEM_WARN Boaz Harrosh
2015-02-24 8:44 ` Boaz Harrosh
2015-02-24 9:06 ` Ingo Molnar
2015-02-24 9:08 ` Boaz Harrosh
2015-02-24 9:07 ` Ingo Molnar
2015-02-24 9:09 ` Boaz Harrosh
2015-02-24 15:00 ` [PATCH 2/3 v4] " Boaz Harrosh
2015-02-24 17:04 ` Dan Williams
2015-02-25 6:36 ` Boaz Harrosh
2015-02-23 12:46 ` [PATCH 3A/3 good] e820: Add the unknown-12 Memory type (DDR3-NvDIMM) Boaz Harrosh
2015-02-23 15:48 ` Andy Lutomirski
2015-02-23 12:48 ` [PATCH 3B/3 fat] e820: dynamic unknown-xxx names (for DDR3-NvDIMM) Boaz Harrosh
2015-02-23 15:49 ` Andy Lutomirski
2015-02-24 7:38 ` Boaz Harrosh
2015-02-25 10:22 ` [PATCH 0/3 v2] e820: Fix handling of NvDIMM chips Ingo Molnar
2015-02-25 14:42 ` Boaz Harrosh
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=54EC262E.9010903@plexistor.com \
--to=boaz@plexistor.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=rcpao.enmotus@gmail.com \
--cc=ross.zwisler@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vgoyal@redhat.com \
--cc=willy@linux.intel.com \
--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).