From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.arm.linux.org.uk,
linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/6] omap iommu: tlb and pagetable primitives
Date: Sat, 17 Jan 2009 16:06:08 +0000 [thread overview]
Message-ID: <20090117160608.GA12341@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20090116083709.18344.74524.stgit@oreo.research.nokia.com>
A few more simple comments...
On Fri, Jan 16, 2009 at 10:37:09AM +0200, Hiroshi DOYU wrote:
> +struct iommu_platform_data {
> + char *name;
const?
> + char *clk_name;
const?
> + int nr_tlb_entries;
> +};
...
> +int install_iommu_arch(const struct iommu_functions *ops)
> +{
> + if (arch_iommu)
> + return -EBUSY;
> +
> + arch_iommu = ops;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(install_iommu_arch);
Exported functions should have some documentation in the standard kernel
documentation format. See Documentation/kernel-doc-nano-HOWTO.txt
> +static int iommu_enable(struct iommu *obj)
> +{
> + int err;
> +
> + BUG_ON(!arch_iommu || !arch_iommu->enable);
Are these run-time BUG_ON checks really worth it? BUG_ON is effectively:
if (condition_is_true)
cause_a_null_pointer_dereference;
So, if you're checking for pointers you're about dereference being NULL,
there's little point - dereferencing the when they're NULL will cause an
oops, and you won't have the overhead of the runtime tests checking them
for NULL. Ditto elsewhere in this file.
> +static u32 *iopte_alloc(struct iommu *obj, u32 *iopgd, u32 da)
> +{
> + u32 *iopte;
> +
> + /* a table has already existed */
> + if (*iopgd)
> + goto pte_ready;
> +
> + /*
> + * do the allocation outside the page table lock
> + */
> + spin_unlock(&obj->page_table_lock);
> + iopte = kmem_cache_zalloc(iopte_cachep, GFP_KERNEL);
> + spin_lock(&obj->page_table_lock);
> +
> + if (!*iopgd) {
> + if (!iopte)
> + return ERR_PTR(-ENOMEM);
> +
> + *iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
> + flush_iopgd_range(iopgd, iopgd);
> +
> +#ifdef DEBUG_VERBOSE
> + dev_dbg(obj->dev, "%s:\ta new pte:%p\n", __func__, iopte);
> +#endif
Not sure wrapping these in DEBUG_VERBOSE is necessary. dev_dbg() is a
no-op unless DEBUG is defined.
> +#ifdef DEBUG
> +static void dump_tlb_entries(struct iommu *obj)
> +{
> + int i;
> + struct iotlb_lock l;
> +
> + clk_enable(obj->clk);
> +
> + pr_info("%8s %8s\n", "cam:", "ram:");
> + pr_info("-----------------------------------------\n");
> +
> + for (i = 0; i < obj->nr_tlb_entries; i++) {
> + struct cr_regs cr;
> + static char buf[4096];
> +
> + iotlb_lock_get(obj, &l);
> + l.vict = i;
> + iotlb_lock_set(obj, &l);
> + iotlb_read_cr(obj, &cr);
> + if (!iotlb_cr_valid(&cr))
> + continue;
> +
> + memset(buf, 0, 4096);
> + iotlb_dump_cr(obj, &cr, buf);
> + pr_info("%s", buf);
Hmm. You call this in relation to an error, but you print everything at
'info' level. Are you sure that's correct?
> +/*
> + * OMAP Device MMU(IOMMU) detection
> + */
> +static int __devinit omap_iommu_probe(struct platform_device *pdev)
> +{
> + int err = -ENODEV;
> + void *p;
> + int irq;
> + struct iommu *obj;
> + struct resource *res;
> + struct iommu_platform_data *pdata = pdev->dev.platform_data;
> +
> + if (pdev->num_resources != 2)
> + return -EINVAL;
> +
> + obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
> + if (!obj)
> + return -ENOMEM;
> +
> + obj->clk = clk_get(NULL, pdata->clk_name);
Avoid passing a NULL struct device except when you have absolutely no other
choice. &pdev->dev looks sensible. By doing this, it also provides us with
a path to fixing the OMAP clk API implementation without having to fix lots
of drivers.
next prev parent reply other threads:[~2009-01-17 16:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 8:37 [PATCH 0/6] arm: omap iommu: add initial support Hiroshi DOYU
2009-01-16 8:37 ` [PATCH 1/6] omap iommu: tlb and pagetable primitives Hiroshi DOYU
2009-01-17 16:06 ` Russell King - ARM Linux [this message]
2009-01-17 20:48 ` David Brownell
2009-01-19 9:44 ` Hiroshi DOYU
2009-01-19 21:58 ` Russell King - ARM Linux
2009-01-19 22:42 ` David Brownell
2009-01-26 13:41 ` Hiroshi DOYU
2009-01-27 21:31 ` Hiroshi DOYU
2009-01-16 8:37 ` [PATCH 2/6] omap iommu: omap2 architecture specific functions Hiroshi DOYU
2009-01-16 8:37 ` [PATCH 3/6] omap iommu: omap3 iommu device registration Hiroshi DOYU
2009-01-17 16:21 ` Russell King - ARM Linux
2009-01-27 21:29 ` Hiroshi DOYU
2009-01-28 10:41 ` Russell King - ARM Linux
2009-01-28 11:37 ` Hiroshi DOYU
2009-01-16 8:37 ` [PATCH 4/6] omap iommu: simple virtual address space management Hiroshi DOYU
2009-01-17 16:57 ` Russell King - ARM Linux
2009-01-27 21:29 ` Hiroshi DOYU
2009-01-16 8:37 ` [PATCH 5/6] omap iommu: entries for Kconfig and Makefile Hiroshi DOYU
2009-01-16 8:37 ` [PATCH 6/6] omap2 " Hiroshi DOYU
2009-01-17 16:59 ` Russell King - ARM Linux
2009-01-22 15:02 ` Hiroshi DOYU
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=20090117160608.GA12341@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=Hiroshi.DOYU@nokia.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.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
Powered by JetHome