From: Ionut Nicu <ionut.nicu@mindbit.ro>
To: "Sapiens, Rene" <rene.sapiens@ti.com>
Cc: Ionut Nicu <ionut.nicu@gmail.com>,
Greg Kroah-Hartman <greg@kroah.com>,
Omar Ramirez Luna <omar.ramirez@ti.com>,
Fernando Guzman Lugo <x0095840@ti.com>,
Felipe Contreras <felipe.contreras@gmail.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
linux-omap <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v2 08/12] staging: tidspbridge: convert rmgr to list_head
Date: Sat, 06 Nov 2010 20:18:27 +0200 [thread overview]
Message-ID: <1289067507.9931.95.camel@atlantis.mindbit.ro> (raw)
In-Reply-To: <AANLkTinvM3W1WRNjw8zd=Yi6_J6uEw-h0efLjMrndCgn@mail.gmail.com>
Hi Rene,
On Fri, 2010-11-05 at 18:07 -0600, Sapiens, Rene wrote:
> Hi Ionut,
>
> On Fri, Nov 5, 2010 at 9:13 AM, Ionut Nicu <ionut.nicu@gmail.com> wrote:
> > Convert the rmgr module of the tidspbridge driver
> > to use struct list_head instead of struct lst_list.
> >
> > Signed-off-by: Ionut Nicu <ionut.nicu@mindbit.ro>
>
> <snip>
>
> > diff --git a/drivers/staging/tidspbridge/rmgr/drv.c b/drivers/staging/tidspbridge/rmgr/drv.c
>
> <snip>
>
> > @@ -492,16 +465,17 @@ u32 drv_get_next_dev_object(u32 hdev_obj)
> > u32 dw_next_dev_object = 0;
> > struct drv_object *pdrv_obj;
> > struct drv_data *drv_datap = dev_get_drvdata(bridge);
> > + struct list_head *curr;
> >
> > DBC_REQUIRE(hdev_obj != 0);
>
> can we remove the DBC_REQUIRE and always check for !hdev_obj?
>
Sounds ok to me.
As a general remark, I personally think that the DBC_* macros should be
replaced with BUG_ON, WARN_ON, but that's a subject for other patches.
What do you think?
> >
> > if (drv_datap && drv_datap->drv_object) {
> > pdrv_obj = drv_datap->drv_object;
> > - if ((pdrv_obj->dev_list != NULL) &&
> > - !LST_IS_EMPTY(pdrv_obj->dev_list)) {
> > - dw_next_dev_object = (u32) lst_next(pdrv_obj->dev_list,
> > - (struct list_head *)
> > - hdev_obj);
> > + if (!list_empty(&pdrv_obj->dev_list)) {
> > + curr = (struct list_head *)hdev_obj;
> > + if (curr->next == &pdrv_obj->dev_list)
>
> Can we use list_is_last() instead?
>
Good point. I'll fix this.
> > + return 0;
> > + dw_next_dev_object = (u32) curr->next;
>
> <snip>
>
> > @@ -573,11 +548,8 @@ int drv_insert_dev_object(struct drv_object *driver_obj,
> > DBC_REQUIRE(refs > 0);
> > DBC_REQUIRE(hdev_obj != NULL);
> > DBC_REQUIRE(pdrv_object);
> > - DBC_ASSERT(pdrv_object->dev_list);
> > -
>
> As a comment for all the functions that are manipulating lists, can we
> check the parameters that they receive?, this applies for some other
> functions in these patches, old lst_* functions were internally validating
> the having of a valid pointer, now i think that we have to add this to each
> function.
>
I don't think we need to put extra checks. The list head pointer will
never be null and I don't see any use cases where the list_head
container structure can be null...
> > - lst_put_tail(pdrv_object->dev_list, (struct list_head *)hdev_obj);
> >
> > - DBC_ENSURE(!LST_IS_EMPTY(pdrv_object->dev_list));
> > + list_add_tail((struct list_head *)hdev_obj, &pdrv_object->dev_list);
>
> <snip>
>
> > @@ -1571,15 +1566,9 @@ int node_enum_nodes(struct node_mgr *hnode_mgr, void **node_tab,
> > *pu_num_nodes = 0;
> > status = -EINVAL;
> > } else {
> > - hnode = (struct node_object *)lst_first(hnode_mgr->
> > - node_list);
> > - for (i = 0; i < hnode_mgr->num_nodes; i++) {
> > - DBC_ASSERT(hnode);
> > - node_tab[i] = hnode;
> > - hnode = (struct node_object *)lst_next
> > - (hnode_mgr->node_list,
> > - (struct list_head *)hnode);
> > - }
> > + i = 0;
>
> just a comment, what if we initialize this "i" when declared and
> remove this line.
>
Ok, will do.
> > + list_for_each_entry(hnode, &hnode_mgr->node_list, list_elem)
> > + node_tab[i++] = hnode;
> > *pu_allocated = *pu_num_nodes = hnode_mgr->num_nodes;
> > }
>
> <snip>
>
> > diff --git a/drivers/staging/tidspbridge/rmgr/rmm.c b/drivers/staging/tidspbridge/rmgr/rmm.c
>
> <snip>
>
> > @@ -145,20 +141,17 @@ int rmm_alloc(struct rmm_target_obj *target, u32 segid, u32 size,
> > if (new_sect == NULL) {
> > status = -ENOMEM;
> > } else {
> > - lst_init_elem((struct list_head *)new_sect);
> > new_sect->addr = addr;
> > new_sect->size = size;
> > new_sect->page = segid;
> > - if (sect == NULL) {
> > + if (sect == NULL)
>
> I think that "sect" can't be NULL at this point... can be?
> can we use: if (list_is_last(§->list_elem, target->ovly_list)) instead?
>
Yes, you are right.
> > /* Put new section at the end of the list */
> > - lst_put_tail(target->ovly_list,
> > - (struct list_head *)new_sect);
> > - } else {
> > + list_add_tail(&new_sect->list_elem,
> > + &target->ovly_list);
> > + else
>
> <snip>
>
> > @@ -333,24 +316,17 @@ bool rmm_free(struct rmm_target_obj *target, u32 segid, u32 dsp_addr, u32 size,
> >
> > } else {
> > /* Unreserve memory */
> > - sect = (struct rmm_ovly_sect *)lst_first(target->ovly_list);
> > - while (sect != NULL) {
> > + list_for_each_entry_safe(sect, tmp, &target->ovly_list,
> > + list_elem) {
> > if (dsp_addr == sect->addr) {
> > DBC_ASSERT(size == sect->size);
> > /* Remove from list */
> > - lst_remove_elem(target->ovly_list,
> > - (struct list_head *)sect);
> > + list_del(§->list_elem);
> > kfree(sect);
> > + ret = true;
> > break;
>
> can we just return true and do not break?
Sure, I will change this.
Regards,
Ionut.
next prev parent reply other threads:[~2010-11-06 18:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 15:13 [PATCH v2 00/12] staging: tidspbridge: various cleanups Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 01/12] staging: tidspbridge: remove gs memory allocator Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 02/12] staging: tidspbridge: remove utildefs Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 03/12] staging: tidspbridge: switch to linux bitmap API Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 04/12] staging: tidspbridge: remove gb bitmap implementation Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 05/12] staging: tidspbridge: rmgr/node.c code cleanup Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 06/12] staging: tidspbridge: convert core to list_head Ionut Nicu
2010-11-05 21:07 ` Sapiens, Rene
2010-11-06 17:21 ` Ionut Nicu
2010-11-08 19:15 ` Sapiens, Rene
2010-11-05 22:12 ` Sapiens, Rene
2010-11-06 17:31 ` Ionut Nicu
2010-11-08 19:16 ` Sapiens, Rene
2010-11-05 15:13 ` [PATCH v2 07/12] staging: tidspbridge: convert pmgr " Ionut Nicu
2010-11-05 22:41 ` Sapiens, Rene
2010-11-07 13:39 ` Ionut Nicu
2010-11-08 19:17 ` Sapiens, Rene
2010-11-05 15:13 ` [PATCH v2 08/12] staging: tidspbridge: convert rmgr " Ionut Nicu
2010-11-06 0:07 ` Sapiens, Rene
2010-11-06 18:18 ` Ionut Nicu [this message]
2010-11-06 18:26 ` Greg KH
2010-11-07 12:11 ` Ionut Nicu
2010-11-07 14:24 ` Nishanth Menon
2010-11-07 15:59 ` Greg KH
2010-11-08 19:18 ` Sapiens, Rene
2010-11-05 15:13 ` [PATCH v2 09/12] staging: tidspbridge: remove custom linked list Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 10/12] staging: tidspbridge: core code cleanup Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 11/12] staging: tidspbridge: pmgr " Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 12/12] staging: tidspbridge: rmgr " Ionut Nicu
2010-11-05 15:43 ` [PATCH v2 00/12] staging: tidspbridge: various cleanups Greg KH
2010-11-05 16:02 ` Ionut Nicu
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=1289067507.9931.95.camel@atlantis.mindbit.ro \
--to=ionut.nicu@mindbit.ro \
--cc=andy.shevchenko@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=greg@kroah.com \
--cc=ionut.nicu@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=omar.ramirez@ti.com \
--cc=rene.sapiens@ti.com \
--cc=x0095840@ti.com \
/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