From: Greg KH <gregkh@linuxfoundation.org>
To: Frank Haverkamp <haver@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, arnd@arndb.de,
cody@linux.vnet.ibm.com, schwidefsky@de.ibm.com,
utz.bacher@de.ibm.com, mmarek@suse.cz, rmallon@gmail.com,
jsvogt@de.ibm.com, MIJUNG@de.ibm.com,
cascardo@linux.vnet.ibm.com, michael@ibmra.de
Subject: Re: [PATCH 3/6] GenWQE Utility functions
Date: Wed, 27 Nov 2013 11:26:59 -0800 [thread overview]
Message-ID: <20131127192659.GD28409@kroah.com> (raw)
In-Reply-To: <1383741943-14609-4-git-send-email-haver@linux.vnet.ibm.com>
On Wed, Nov 06, 2013 at 01:45:40PM +0100, Frank Haverkamp wrote:
> +/**
> + * init_crc32() - Prepare a lookup table for fast crc32 calculations
> + *
> + * Existing kernel functions seem to use a different polynom,
> + * therefore we could not use them here.
> + *
> + * Genwqe's Polynomial = 0x20044009
> + */
> +#define CRC32_POLYNOMIAL 0x20044009
> +static u32 crc32_tab[256]; /* crc32 lookup table */
> +
> +void init_crc32(void)
That's a _very_ generic function name to now be global in the whole
kernel.
And why not just add new polynomial functionality to the existing crc32
in-kernel code instead of rolling your own here?
> +static void genwqe_dump_sgl(struct genwqe_dev *cd, struct sg_entry *sgl,
> + size_t sgl_size)
> +{
> + unsigned int i, j;
> + struct pci_dev *pci_dev = cd->pci_dev;
> +
> + for (j = 0, i = 0; i < sgl_size/sizeof(struct sg_entry); i++, j++) {
> + if (j == 8) {
> + dev_info(&pci_dev->dev, " --\n");
> + j = 0;
> + }
> + dev_info(&pci_dev->dev, " %016llx %08x %08x %s\n",
> + be64_to_cpu(sgl[i].target_addr),
> + be32_to_cpu(sgl[i].len),
> + be32_to_cpu(sgl[i].flags),
> + (be32_to_cpu(sgl[i].len) > PAGE_SIZE) ? "C" : "");
> +
> + if (be32_to_cpu(sgl[i].flags) == SG_END_LIST)
> + break;
> + }
> +}
That's a lot of kernel log mess, why?
> +/**
> + * free_user_pages() - Give pinned pages back
> + *
> + * Documentation of get_user_pages is in mm/memory.c:
> + *
> + * If the page is written to, set_page_dirty (or set_page_dirty_lock,
> + * as appropriate) must be called after the page is finished with, and
> + * before put_page is called.
> + */
> +static int free_user_pages(struct page **page_list, unsigned int nr_pages,
> + int dirty)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < nr_pages; i++) {
> + if (page_list[i] != NULL) {
> + if (dirty)
> + set_page_dirty_lock(page_list[i]);
> + put_page(page_list[i]);
> + }
> + }
> + return 0;
> +}
> +
> +/**
> + * user_vmap() - Map user-space memory to virtual kernel memory
> + * @cd: pointer to genwqe device
> + * @m: mapping params
> + * @uaddr: user virtual address
> + * @size: size of memory to be mapped
> + *
> + * We need to think about how we could speed this up. Of course it is
> + * not a good idea to do this over and over again, like we are
> + * currently doing it. Nevertheless, I am curious where on the path
> + * the performance is spend. Most probably within the memory
> + * allocation functions, but maybe also in the DMA mapping code.
> + *
> + * Restrictions: The maximum size of the possible mapping currently depends
> + * on the amount of memory we can get using kzalloc() for the
> + * page_list and pci_alloc_coherent for the sg_list.
> + * The sg_list is currently itself not scattered, which could
> + * be fixed with some effort. The page_list must be split into
> + * PAGE_SIZE chunks too. All that will make the complicated
> + * code more complicated.
> + *
> + * Return: 0 if success
> + */
> +int user_vmap(struct genwqe_dev *cd, struct dma_mapping *m, void *uaddr,
> + unsigned long size, struct ddcb_requ *req)
Again, _very_ generic global symbol name. Please audit all of these.
And shouldn't this just be a core mm function? Why is this in a driver?
> +/**
> + * user_vunmap() - Undo mapping of user-space memory to virtual kernel memory
> + * @cd: pointer to genwqe device
> + * @m: mapping params
> + */
> +int user_vunmap(struct genwqe_dev *cd, struct dma_mapping *m,
> + struct ddcb_requ *req)
Same as above.
thanks,
greg k-h
next prev parent reply other threads:[~2013-11-27 19:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 12:45 [PATCH 0/6] Generic WorkQueue Engine (GenWQE) device driver (v7) Frank Haverkamp
2013-11-06 12:45 ` [PATCH 1/6] GenWQE PCI support, health monitoring and recovery Frank Haverkamp
2013-11-27 19:16 ` Greg KH
2013-12-03 13:35 ` Frank Haverkamp
2013-12-03 14:30 ` Greg KH
2013-12-03 14:46 ` Frank Haverkamp
2013-12-03 15:05 ` Arnd Bergmann
2013-12-04 9:59 ` Frank Haverkamp
2013-11-27 19:20 ` Greg KH
2013-12-03 13:49 ` Frank Haverkamp
2013-12-03 14:30 ` Greg KH
2013-11-06 12:45 ` [PATCH 2/6] GenWQE Character device and DDCB queue Frank Haverkamp
2013-11-06 12:45 ` [PATCH 3/6] GenWQE Utility functions Frank Haverkamp
2013-11-27 19:26 ` Greg KH [this message]
2013-12-03 13:21 ` Frank Haverkamp
2013-11-06 12:45 ` [PATCH 4/6] GenWQE Debugfs interfaces Frank Haverkamp
2013-11-06 12:45 ` [PATCH 5/6] GenWQE Sysfs interfaces Frank Haverkamp
2013-11-27 19:22 ` Greg KH
2013-12-03 12:53 ` Frank Haverkamp
2013-12-03 14:28 ` Greg KH
2013-11-06 12:45 ` [PATCH 6/6] GenWQE Enable driver Frank Haverkamp
2013-11-22 13:37 ` [PATCH 0/6] Generic WorkQueue Engine (GenWQE) device driver (v7) Frank Haverkamp
2013-11-22 16:52 ` Greg KH
2013-11-27 10:26 ` Frank Haverkamp
-- strict thread matches above, loose matches on Subject: below --
2013-12-09 12:30 [PATCH 0/6] Generic WorkQueue Engine (GenWQE) device driver (v10) Frank Haverkamp
2013-12-09 12:30 ` [PATCH 3/6] GenWQE Utility functions Frank Haverkamp
2013-12-05 14:15 [PATCH 0/6] Generic WorkQueue Engine (GenWQE) device driver (v9) Frank Haverkamp
2013-12-05 14:15 ` [PATCH 3/6] GenWQE Utility functions Frank Haverkamp
2013-12-03 14:28 [PATCH 0/6] Generic WorkQueue Engine (GenWQE) device driver (v8) Frank Haverkamp
2013-12-03 14:28 ` [PATCH 3/6] GenWQE Utility functions Frank Haverkamp
2013-11-05 8:44 [PATCH 0/6] Generic WorkQueue Engine (GenWQE) device driver (v6) Frank Haverkamp
2013-11-05 8:44 ` [PATCH 3/6] GenWQE Utility functions Frank Haverkamp
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=20131127192659.GD28409@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=MIJUNG@de.ibm.com \
--cc=arnd@arndb.de \
--cc=cascardo@linux.vnet.ibm.com \
--cc=cody@linux.vnet.ibm.com \
--cc=haver@linux.vnet.ibm.com \
--cc=jsvogt@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@ibmra.de \
--cc=mmarek@suse.cz \
--cc=rmallon@gmail.com \
--cc=schwidefsky@de.ibm.com \
--cc=utz.bacher@de.ibm.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