linux-kernel - RE: [Patch 2/3] via-sdmmc: via-sdmmc.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 22 Dec 2008 15:17:56 +0800
From:	<JosephChan@....com.tw>
To:	<arnd@...db.de>, <ben-linux@...ff.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: RE: [Patch 2/3] via-sdmmc: via-sdmmc.c

> On Wednesday 17 December 2008, JosephChan@....com.tw wrote:
> 
> > > struct pcictrlreg __iomem *pcr =
> > > vcrdr_chip->pcictrl_mmiobase; pm_pcictrl_reg->pcisdclk_reg = 
> > > readb(&pcr->pcisdclk_reg);
> > > 
> > > Of course, your code is doing the same things effectively and 
> > > entirely ok here.
> > 
> > We'll modify the code according to your suggestions..
> 
> Ben Dooks didn't like that suggestion, and I don't care that 
> much, so you may want to leave this one alone.

OK, I see that. 

>  
> > We'll try to modify the code like below, but need more tests.
> > 
> > In via_sdc_preparedata() function:
> > 
> >     int sg_cnt;
> > 
> >     sg_cnt = dma_map_sg(mmc_dev(host->mmc), data->sg, 
> data->sg_len, (data->flags & MMC_DATA_READ) ? DMA_FROM_DEVICE 
> : DMA_TO_DEVICE);
> >     WARN_ON(sg_cnt != 1);
> 
> AFAICT, it would be perfectly fine for sg_cnt to be larger 
> than 1, just not smaller. I don't understand yet how your 
> hardware would deal with this though.
> 
> >     via_set_ddma(host->chip, sg_dma_address(data->sg), 
> > sg_dma_len(data->sg), (data->flags & MMC_DATA_READ) ? 
> DMA_FROM_DEVICE 
> > : DMA_TO_DEVICE );
> 
> Ideally, the via_set_ddma function would be able to program 
> the scatterlist into the hardware registers directly. If this 
> doesn't work, you may be able to look over all elements in 
> the list manually. If this doesn't work either, you will have 
> to go back to your original code, and replace the 
> virt_to_phys conversion with dma_map_single()/dma_unmap_single().

We've checked the mmc_core as follows, that's way we thought in that way before.
        brq.data.sg = mq->sg;
        brq.data.sg_len = mmc_queue_map_sg(mq);

        mmc_queue_bounce_pre(mq);

        if (brq.data.blocks !=
            (req->nr_sectors >> (md->block_bits - 9))) {
            data_size = brq.data.blocks * brq.data.blksz;
            for (sg_pos = 0; sg_pos < brq.data.sg_len; sg_pos++) {
                data_size -= mq->sg[sg_pos].length;
                if (data_size <= 0) {
                    mq->sg[sg_pos].length += data_size;
                    sg_pos++;
                    break;
                }
            }
            brq.data.sg_len = sg_pos;
        }

       mmc_wait_for_req(card->host, &brq.mrq);
       mmc_queue_bounce_post(mq);

Also, we are trying to use the dma_map_single()/dma_unmap_single() functions. We think it's easiler to implement.


> > > What are your criteria for deciding which events to handle in 
> > > interrupt context or in tasklet context? Are some of them 
> extremely 
> > > performance critical?
> > 
> > The criteria are: 
> > 1. Because the SD card detect operations need delay about 1 
> ms, so it should not be implemented in interrupt context. So 
> we implement it by via_sdc_tasklet_card.
> 
> I would argue that 1ms is too long for tasklet (softirq) 
> context as well, and this should better be moved to a work queue.
> 
> > 2. The STSTATUS_REG register must be reset quickly, so it 
> should be implemented in interrupt context.
> > 3. In order to finish one “request” from the mmc_block 
> layer quickly, all operations (that can finished quickly) 
> before the end of the “request” should be implemented in 
> interrupt context.
> 
> It's still hard to tell what 'quickly' means here. There is a 
> latency for entering work queues or tasklets, but if the 
> system is idle, that should not be noticable. OTOH, if the 
> system is busy, it may be worthwhile doing something more 
> important before working on the MMC workqueue.
> 
> It's probably something you should measure. If you don't find 
> a significant slowdown by moving to a work queue 
> implementation, I would recommend doing that in order to 
> simplify the driver.
> 

We're checking and hope to provide a significant way for this in next patch.