mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Michel Stam <michel@reverze.net>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Barebox x86 IDE support
Date: Tue, 25 Mar 2014 12:04:24 +0100	[thread overview]
Message-ID: <533162B8.8050300@reverze.net> (raw)
In-Reply-To: <20140325081815.GM17250@pengutronix.de>


[-- Attachment #1.1: Type: text/plain, Size: 2892 bytes --]

Hello Sascha,

I will repost the patches separately as you requested.

With regard to your comment below, this was somewhat intentional, as I 
understood:
> struct resource iomem_resource = {
>         .start = 0,
>         .end = 0xffffffff,
>         .name = "iomem",
>         .children = LIST_HEAD_INIT(iomem_resource.children),
> };
as "I/O and memory resource". This is also why I check on the resource 
type in request_region( ):
>         /*
>          * We keep the list of child resources ordered which helps
>          * us searching for conflicts here.
>          */
>         list_for_each_entry(r, &parent->children, sibling) {
>                 if (end < r->start)
>                         goto ok;
>                 if (start > r->end)
>                         continue;
>
>                 if (type != resource_type(r->parent))
>                         continue;
I retain one resource tree that way, also for if people decide to add 
DMA or IRQ's in the future. The iteration function skips the resource if 
the types do not match. To me the discussion seems the difference 
between one linked list for every resource type (== more work if a new 
type is added), or a single linked list with a type field (new resource 
type == new integer constant, no more).

I would like to hear your thoughts on that.

to be continued after the posting.

Cheers,

Michel
On 03/25/2014 09:18 AM, Sascha Hauer wrote:
> Hi Michel,
>
> On Mon, Mar 24, 2014 at 10:37:48AM +0100, Stam, Michel [FINT] wrote:
>> Hello maintainers,
>>
>> I was wondering if one of you has had time to verify these patches and apply them to trunk?
> Could you send the patches as a series so that it's easier to comment on
> the patches on the list?
>
> There are some things to comment on, I think the most important one is
> this:
>
>> +/*
>> + * request an io region inside the io space
>> + */
>> +struct resource *request_io_region(const char *name,
>> +		resource_size_t start, resource_size_t end,int type)
>> +{
>> +	return request_region(&iomem_resource, name, start, end, type);
>> +}
>>
> You request here from the iomem resource, but ioports are a completely
> separate resource, so you have to use a new toplevel resource like
> this:
>
> /* The root resource for the whole io space */
> struct resource io_resource = {
> 	.start = 0,
> 	.end = 0xffffffff,
> 	.name = "ioport",
> 	.children = LIST_HEAD_INIT(io_resource.children),
> };
>
> /*
>   * request an io region inside the io space
>   */
> struct resource *request_io_region(const char *name,
> 		resource_size_t start, resource_size_t end)
> {
> 	return request_region(&io_resource, name, start, end, IORESOURCE_IO);
> }
>
> The 'type' argument to request_io_region is unnecessary since the
> function name already implies it, right?
>
> Sascha
>



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4278 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2014-03-25 11:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-24  9:37 Stam, Michel [FINT]
2014-03-25  8:18 ` Sascha Hauer
2014-03-25 11:04   ` Michel Stam [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-03-14 17:01 Stam, Michel [FINT]

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=533162B8.8050300@reverze.net \
    --to=michel@reverze.net \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.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