linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).