linux-kernel - Re: [PATCH] mmc: align data size for host which only supports power-of-2 block

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:	Fri, 10 Apr 2009 23:01:11 +0200
From:	Pierre Ossman <drzeus-mmc@...eus.cx>
To:	"Cai, Cliff" <Cliff.Cai@...log.com>
Cc:	"Bryan Wu" <cooloney@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc: align data size for host which only supports
 power-of-2 block

On Tue, 7 Apr 2009 16:34:37 +0800
"Cai, Cliff" <Cliff.Cai@...log.com> wrote:

>  
> 
> >-----Original Message-----
> >From: Pierre Ossman [mailto:drzeus-mmc@...eus.cx] 
> >Sent: Monday, April 06, 2009 3:09 AM
> >To: Cai, Cliff
> >Cc: Bryan Wu; linux-kernel@...r.kernel.org
> >Subject: Re: [PATCH] mmc: align data size for host which only 
> >supports power-of-2 block
> >
> >On Thu, 26 Mar 2009 10:22:54 +0800
> >"Cai, Cliff" <Cliff.Cai@...log.com> wrote:
> >
> >> >
> >> >mmc_align_data_size() shouldn't be adjusting the size to 
> >something it 
> >> >can easily determine that it's invalid.
> >> 
> >> Should I create a new function to do the power-of-2 adjustment?
> >> Or any ideal way to do it?
> >
> >That function is the correct place. My point was that we need 
> >to check after the adjustment that we didn't violate any of 
> >the other restrictions the driver has set. If we do, we should 
> >just return the original value.
> 
> What are other restrictions?I don't see any other restrictions on data
> size in current host driver
> Except 4 byte alignment.
> 

The ones that are in the mmc_host structure:

        /* host specific block data */
        unsigned int            max_seg_size;   /* see blk_queue_max_segment_size */
        unsigned short          max_hw_segs;    /* see blk_queue_max_hw_segments */
        unsigned short          max_phys_segs;  /* see blk_queue_max_phys_segments */
        unsigned short          unused;
        unsigned int            max_req_size;   /* maximum number of bytes in one req */
        unsigned int            max_blk_size;   /* maximum size of one mmc block */
        unsigned int            max_blk_count;  /* maximum number of blocks in one req */

If you adjust a transfer from 1100 bytes to 2048, that could exceed the
limit of 2047 bytes some controllers have.

> 
> >> Otherwise,the SDH almost can't be used as sdio host.
> >
> >Unfortunately I think this controller will be very unsuitable 
> >as an SDIO controller anyway with that restriction.
> 
> Yes,But since we need to support some SDIO devices according to our
> customers'
> Requests ,I think we have no other choice of this.
> 

They should be prepared for the fact that many SDIO devices cannot be
made to work with a controller with these bugs though. The function
you're modifying is only to optimise the transfer and is not mandatory
for SDIO drivers to call in any way.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org
  TigerVNC, core developer          http://www.tigervnc.org

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/