Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 7月, 2008 34 次提交
  3. 27 7月, 2008 6 次提交
    • H
      [SCSI] replace __FUNCTION__ with __func__ · cadbd4a5
      由 Harvey Harrison 提交于 
      [jejb: fixed up a ton of missed conversions.

 All of you are on notice this has happened, driver trees will now
 need to be rebased]
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Cc: SCSI List <linux-scsi@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      cadbd4a5
    • A
      [SCSI] extend the last_sector_bug flag to cover more sectors · 2b142900
      由 Alan Jenkins 提交于 
      The last_sector_bug flag was added to work around a bug in certain usb
cardreaders, where they would crash if a multiple sector read included the
last sector. The original implementation avoids this by e.g. splitting an 8
sector read which includes the last sector into a 7 sector read, and a single
sector read for the last sector.  The flag is enabled for all USB devices.

This revealed a second bug in other usb cardreaders, which crash when they
get a multiple sector read which stops 1 sector short of the last sector.
Affected hardware includes the Kingston "MobileLite" external USB cardreader
and the internal USB cardreader on the Asus EeePC.

Extend the last_sector_bug workaround to ensure that any access which touches
the last 8 hardware sectors of the device is a single sector long.  Requests
are shrunk as necessary to meet this constraint.

This gives us a safety margin against potential unknown or future bugs
affecting multi-sector access to the end of the device.  The two known bugs
only affect the last 2 sectors.  However, they suggest that these devices
are prone to fencepost errors and that multi-sector access to the end of the
device is not well tested.  Popular OS's use multi-sector accesses, but they
rarely read the last few sectors.  Linux (with udev & vol_id) automatically
reads sectors from the end of the device on insertion.  It is assumed that
single sector accesses are more thoroughly tested during development.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      2b142900
    • D
      avr32: some mmc/sd cleanups · 3c26e170
      由 David Brownell 提交于 
      Minor cleanups for the MMC/SD support on avr32:

 - Make at32_add_device_mci() properly initialize "missing"
   platform data ... so boards like STK1002 won't try GPIO 0.

 - Switch over to gpio_is_valid() instead of testing for only
   one designated value.

 - Provide STK1002 platform data for the unlikely case that
   switches are set so first Ethernet controller isn't in use.
   (That's the only way to get card detect and writeprotect
   switch sensing on the STK1000.)

And get rid of one "unused variable" warning.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      3c26e170
    • H
      Merge commit 'upstream/master' · eda3d8f5
      由 Haavard Skinnemoen 提交于
      eda3d8f5
    • R
      [ARM] Fix shared mmap when more than two maps of the same file exist · 53cdb27a
      由 Russell King 提交于 
      The shared mmap code works fine for the test case, which only checked
for two shared maps of the same file.  However, three shared maps
result in one mapping remaining cached, resulting in stale data being
visible via that mapping.  Fix this.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      53cdb27a
    • R
      [ARM] fix VIPT/VIVT macro optimisations, add comments · daf93dd5
      由 Russell King 提交于 
      cacheflush.h was doing:

... VIVT only stuff
... VIPT only stuff
... VIVT or VIPT stuff

which is clearly bogus - we would only ever use the "VIVT or VIPT" case
when both VIVT and VIPT are not selected.  Fix this.

Add comments to each case, including noting the impossibility of
correctly detecting the cache type of ARM926 and ARMv6 cores from
the cache type register in the "VIVT or VIPT" case.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      daf93dd5