From: Christoph Hellwig <hch@infradead.org>
To: Lauri Kasanen <cand@gmx.com>
Cc: linux-mips@vger.kernel.org, tsbogend@alpha.franken.de,
axboe@kernel.dk, linux-block@vger.kernel.org,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 3/3 v7] block: Add n64 cart driver
Date: Wed, 20 Jan 2021 14:44:05 +0000 [thread overview]
Message-ID: <20210120144405.GA3763056@infradead.org> (raw)
In-Reply-To: <20210115133559.84b2997dc326c277c4d91503@gmx.com>
> +
> +MODULE_AUTHOR("Lauri Kasanen <cand@gmx.com>");
> +MODULE_DESCRIPTION("Driver for the N64 cart");
> +MODULE_LICENSE("GPL");
> +
> +#define BUFSIZE (64 * 1024)
Maybe use SZ_64K here?
> + void *dst = bio_data(req->bio);
> +
> + if (bstart + len > size)
> + return BLK_STS_IOERR;
> +
> + bstart += start;
> +
> + while (len) {
> + const u32 curlen = len < BUFSIZE ? len : BUFSIZE;
> +
> + dma_cache_inv((unsigned long) buf, curlen);
dma_cache_inv is not a public API, but only a helper for the DMA API.
> + n64cart_wait_dma();
> +
> + barrier();
> + n64cart_write_reg(PI_DRAM_REG, dma_addr);
> + barrier();
barrier is just a compiler barrier. But the mmio APIs already include
actual cpu barriers where applicable, so I don't think you need these at
al.
> + n64cart_write_reg(PI_CART_REG, (bstart | 0x10000000) & 0x1FFFFFFF);
Overly long line. Also this looks a little too magic, can you explain
what is going on here with symbolic constants and&or a helper?
> +
> + do {
> + err = get_seg(req);
> + } while (blk_update_request(req, err, blk_rq_cur_bytes(req)));
> +
> + blk_mq_end_request(req, BLK_STS_OK);
This should be __blk_mq_end_request given that you call
blk_update_request manually.
> + major = register_blkdev(0, "n64cart");
No need to call register_blkdev in a new driver, just set the
GENHD_FL_EXT_DEVT flag in struct gendisk.
> + buf = kmalloc(BUFSIZE, GFP_DMA | GFP_KERNEL);
> + if (!buf) {
> + err = -ENOMEM;
> + goto fail_queue;
> + }
> + dma_addr = virt_to_phys(buf);
Please use dma_aloc_noncoherent to allocate dma memory. And then
use the dma_sync_single_for_{device,cpu} to transfer ownership to
and from the device.
Just curious: wouldn't it make more sense to implement this as a bio
based driver with a helper thread? It doesn't look like blk-mq provides
you a lot of benefits here. And then we could make the blk-mq code
optional and you could save a fair amount of a kernel memory on your
rather constrained device.
next prev parent reply other threads:[~2021-01-20 15:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 11:35 [PATCH 3/3 v7] block: Add n64 cart driver Lauri Kasanen
2021-01-20 14:44 ` Christoph Hellwig [this message]
2021-01-20 15:20 ` Lauri Kasanen
2021-01-20 15:42 ` Christoph Hellwig
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=20210120144405.GA3763056@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=cand@gmx.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=tsbogend@alpha.franken.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;
as well as URLs for NNTP newsgroup(s).