- 11 9月, 2011 17 次提交
-
-
由 Axel Lin 提交于
Signed-off-by: NAxel Lin <axel.lin@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Axel Lin 提交于
Signed-off-by: NAxel Lin <axel.lin@gmail.com> Acked-by: NWan ZongShun <mcuos.com@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Axel Lin 提交于
The implementation of nand_release() already call mtd_device_unregister(), no need to call it again. Signed-off-by: NAxel Lin <axel.lin@gmail.com> Acked-by: NJamie Iles <jamie@jamieiles.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Brian Norris 提交于
I believe this TODO was unnecessary back when it was introduced: commit d1e1f4e4 mtd: nand: add support for reading ONFI parameters... Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Dmitry Eremin-Solenikov 提交于
Since 'cmdline, NULL' is now a default for parse_mtd_partitions, don't specify this in every driver, instead pass NULL to force parse_mtd_partitions to use default. Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Dmitry Eremin-Solenikov 提交于
Lots of MTD devices default to cmdlinepart, NULL as partition parsing order. Make it a default. Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Dmitry Eremin-Solenikov 提交于
There is no need to guard mtd->name with CONFIG_MTD_CMDLINE_PARTS as name can be used by other parts. Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Dmitry Eremin-Solenikov 提交于
physmap_configure() and physmap_set_partitions() have no users in kernel. Out of kernel users should have been converted to regular platform device long ago. Drop support for this obsolete API. Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Dmitry Eremin-Solenikov 提交于
It's a Ceiva/Polaroid PhotoMax Digital Picture Frame. Support for it was commited before 2.6.12-rc2, current git contains no functional changes since it's start. Driver containing MTD support for that board was broken for some time already. Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Jiri Pinkava 提交于
This delay is meaningless. If delay is needed it is device specific and must be reimplemented by specific driver, otherwise no delay is needed. Signed-off-by: NJiri Pinkava <jiri.pinkava@vscht.cz> Acked-by: NVimal Singh <vimal.newwork@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Dmitry Eremin-Solenikov 提交于
Currently atmel_nand driver used by AT91 and AVR32 calls a special callback which return nand partition table and number of partitions. However in all boards this callback returns just static data. So drop this callback and make atmel_nand use partition table provided statically via platform_data. Nicolas Ferre: I am in favor for a mainline inclusion through linux-mtd tree. Hans-Christian Egtvedt: I'm fine by sending the changes for AVR32 through linux-mtd Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by: NHans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Brian Norris 提交于
According to our new prefix rules, we should rename NAND_CREATE_EMPTY_BBT with a NAND_BBT prefix, i.e., NAND_BBT_CREATE_EMPTY. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Brian Norris 提交于
The NAND_CREATE_EMPTY_BBT flag was added by commit: 453281a9 mtd: nand: introduce NAND_CREATE_EMPTY_BBT This flag is not used within the kernel and not explained well, so I took the liberty to edit its comments. Also, this is a BBT-related flag (and closely tied with NAND_BBT_CREATE) so I'm moving it to bbm.h next to NAND_BBT_CREATE, thus requiring that we use the flag in nand_chip.bbt_options, *not* in nand_chip.options. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Brian Norris 提交于
Recall the recently added prefix requirements: * "NAND_" for flags in nand.h, used in nand_chip.options * "NAND_BBT_" for flags in bbm.h, used in nand_chip.bbt_options or in nand_bbt_descr.options Thus, I am changing NAND_USE_FLASH_BBT to NAND_BBT_USE_FLASH. Again, this flag is found in bbm.h and so should NOT be used in the "nand_chip.options" field. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Brian Norris 提交于
This patch works with the following three flags from two headers (nand.h and bbm.h): (1) NAND_USE_FLASH_BBT (nand.h) (2) NAND_USE_FLASH_BBT_NO_OOB (nand.h) (3) NAND_BBT_NO_OOB (bbm.h) These flags are all related and interdependent, yet they were in different headers. Flag (2) is simply the combination of (1) and (3) and can be eliminated. This patch accomplishes the following: * eliminate NAND_USE_FLASH_BBT_NO_OOB (i.e., flag (2)) * move NAND_USE_FLASH_BBT (i.e., flag (1)) to bbm.h It's important to note that because (1) and (3) are now both found in bbm.h, they should NOT be used in the "nand_chip.options" field. I removed a small section from the mtdnand DocBook because it referes to NAND_USE_FLASH_BBT in nand.h, which has been moved to bbm.h. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Brian Norris 提交于
This patch handles the problems we've been having with using conflicting flags from nand.h and bbm.h in the same nand_chip.options field. We should try to separate these two spaces a little more clearly, and so I have added a bbt_options field to nand_chip. Important notes about nand_chip fields: * bbt_options field should contain ONLY flags from bbm.h. They should be able to pass safely to a nand_bbt_descr data structure. - BBT option flags start with the "NAND_BBT_" prefix. * options field should contian ONLY flags from nand.h. Ideally, they should not be involved in any BBT related options. - NAND chip option flags start with the "NAND_" prefix. * Every flag should have a nice comment explaining what the flag is. While this is not yet the case on all existing flags, please be sure to write one for new flags. Even better, you can help document the code better yourself! Please try to follow these conventions to make everyone's lives easier. Among the flags that are being moved to the new bbt_options field throughout various drivers, etc. are: * NAND_BBT_SCANLASTPAGE * NAND_BBT_SCAN2NDPAGE and there will be more to come. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Brian Norris 提交于
This patch reverts most of: commit 58373ff0 mtd: nand: more BB Detection refactoring and dynamic scan options According to the discussion at: http://lists.infradead.org/pipermail/linux-mtd/2011-May/035696.html the NAND_BBT_SCANBYTE1AND6 flag, although technically valid, can break some existing ECC layouts that use the 6th byte in the OOB for ECC data. Furthermore, we apparently do not need to scan both bytes 1 and 6 in the OOB region of the devices under consideration; instead, we only need to scan one or the other. Thus, the NAND_BBT_SCANBYTE1AND6 flag is at best unnecessary and at worst a regression. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
- 15 8月, 2011 2 次提交
-
-
由 Axel Lin 提交于
Signed-off-by: NAxel Lin <axel.lin@gmail.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Joe Perches 提交于
Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
- 14 8月, 2011 16 次提交
-
-
由 Seungwon Jeon 提交于
Host driver can't get a hint of DDR mode through ios->ddr flag anymore. ios->timing is currently used to inform DDR mode as a substitute. And capability of MMC_CAP_MMC_HIGHSPEED is added for DDR support. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Acked-by: NWill Newton <will.newton@imgtec.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Jaehoon Chung 提交于
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andy Shevchenko 提交于
When timeout_clk is calculated the host->clock could be zero. So, instead of host->clock the calculation now uses mmc->f_max. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andy Shevchenko 提交于
This moves the calculation below the assignment of mmc->f_max, which we need for calculating timeout_clk in the next patch in this series. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andy Shevchenko 提交于
Sometimes host->clock could be zero which is a legal situation. This patch checks host->clock before usage as a denominator when timeout is calculated. A similar patch is applied for mmc core (see commit e9b86841, "mmc: fix division by zero in MMC core"). Without this patch, the execution of the sdhci_calc_timeout could end up with a backtrace: <0>[ 4.014319] divide error: 0000 [#1] PREEMPT SMP <4>[ 4.014352] Modules linked in: g_ether <4>[ 4.014376] <4>[ 4.014393] Pid: 33, comm: kworker/u:2 Not tainted 3.0.0+ #646 <4>[ 4.014421] EIP: 0060:[<c12fa38e>] EFLAGS: 00010046 CPU: 1 <4>[ 4.014449] EIP is at sdhci_calc_timeout+0x2e/0x100 <4>[ 4.014468] EAX: 00000000 EBX: f5930fc8 ECX: 00000000 EDX: 00000000 <4>[ 4.014488] ESI: f5291de8 EDI: f5291db8 EBP: f5291c6c ESP: f5291c50 <4>[ 4.014508] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 <0>[ 4.014529] Process kworker/u:2 (pid: 33, ti=f5290000 task=f53065a0 task.ti=f5290000) <0>[ 4.014546] Stack: <4>[ 4.014557] 00000082 c1054fdd f5291c78 04000000 f5930fc8 f5291de8 f5291db8 f5291cac <4>[ 4.014611] c12fab7c c107a98b f5291c88 c13b6d3f f593109c f5882000 f5291cac c1054fdd <4>[ 4.014663] 00000000 00000000 f5882000 00000082 f5930fc8 f5291db8 0000000a f5291ccc <0>[ 4.014716] Call Trace: <4>[ 4.014743] [<c1054fdd>] ? mod_timer+0x11d/0x380 <4>[ 4.014770] [<c12fab7c>] sdhci_prepare_data+0x2c/0x3a0 <4>[ 4.014798] [<c107a98b>] ? trace_hardirqs_off+0xb/0x10 <4>[ 4.014827] [<c13b6d3f>] ? _raw_spin_unlock_irqrestore+0x2f/0x60 <4>[ 4.014854] [<c1054fdd>] ? mod_timer+0x11d/0x380 <4>[ 4.014880] [<c12fc7db>] sdhci_send_command+0xdb/0x210 <4>[ 4.014906] [<c12fd5f3>] sdhci_request+0xc3/0x150 <4>[ 4.014932] [<c12ec56a>] mmc_start_request+0xda/0x200 <4>[ 4.014960] [<c120d7c2>] ? __raw_spin_lock_init+0x32/0x60 <4>[ 4.014989] [<c1066a85>] ? __init_waitqueue_head+0x35/0x50 <4>[ 4.015015] [<c12ec70b>] mmc_wait_for_req+0x7b/0x90 <4>[ 4.015045] [<c12f0c67>] mmc_send_cxd_data+0xf7/0x130 <4>[ 4.015076] [<c12ecbc0>] ? mmc_erase+0x140/0x140 <4>[ 4.015102] [<c12f139d>] mmc_send_ext_csd+0x1d/0x20 <4>[ 4.015125] [<c12efef0>] mmc_get_ext_csd+0x70/0x140 <4>[ 4.015151] [<c12effe8>] mmc_compare_ext_csds+0x28/0x190 <4>[ 4.015176] [<c12f039f>] mmc_init_card+0x24f/0x650 <4>[ 4.015201] [<c13b6d5d>] ? _raw_spin_unlock_irqrestore+0x4d/0x60 <4>[ 4.015226] [<c107fd9c>] ? trace_hardirqs_on_caller+0x11c/0x160 <4>[ 4.015255] [<c12f09a4>] mmc_attach_mmc+0xa4/0x190 <4>[ 4.015282] [<c12ee3f0>] mmc_rescan+0x210/0x240 <4>[ 4.015311] [<c105f9b6>] process_one_work+0x176/0x550 <4>[ 4.015336] [<c105f93a>] ? process_one_work+0xfa/0x550 <4>[ 4.015360] [<c12ee1e0>] ? mmc_init_erase+0x140/0x140 <4>[ 4.015385] [<c1061c2a>] worker_thread+0x12a/0x2c0 <4>[ 4.015410] [<c1061b00>] ? manage_workers.clone.18+0x100/0x100 <4>[ 4.015437] [<c1066244>] kthread+0x74/0x80 <4>[ 4.015463] [<c10661d0>] ? __init_kthread_worker+0x60/0x60 <4>[ 4.015490] [<c13b7dfa>] kernel_thread_helper+0x6/0xd <0>[ 4.015507] Code: 57 89 d7 56 53 89 c3 83 ec 10 8b 40 04 8b 72 28 f6 c4 10 89 45 f0 0f 85 91 00 00 00 85 f6 0f 84 c1 00 00 00 8b 4e 04 31 d2 89 c8 <f7> 73 58 ba d3 4d 62 10 89 c1 8b 06 f7 e2 c1 ea 06 01 d1 f7 45 <0>[ 4.015829] EIP: [<c12fa38e>] sdhci_calc_timeout+0x2e/0x100 SS:ESP 0068:f5291c50 Reported-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andy Shevchenko 提交于
This reverts commit 4b01681c, which introduced a new potential divide by zero in the process of fixing one. The subsequent commits attempt to fix the issue properly. Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Axel Lin 提交于
Fix below compile warning: CC drivers/mmc/host/tmio_mmc.o drivers/mmc/host/tmio_mmc.c: In function 'tmio_mmc_suspend': drivers/mmc/host/tmio_mmc.c:30: warning: unused variable 'mmc' drivers/mmc/host/tmio_mmc.c: In function 'tmio_mmc_resume': drivers/mmc/host/tmio_mmc.c:45: warning: unused variable 'mmc' Signed-off-by: NAxel Lin <axel.lin@gmail.com> Acked-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Tony Lin 提交于
Apply a workaround for the imx eSDHC controller to avoid missing card interrupts. This makes SDIO work. Signed-off-by: NTony Lin <tony.lin@freescale.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Mark Brown 提交于
A header change has removed an implicit inclusion of module.h, breaking the build due to the use of THIS_MODULE. Fix that. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Shashidhar Hiremath 提交于
The mask used inside this macro was assuming Buffer_Size1's [BS1's] width to be 14 bits, it is actually 13 bits. Modify masks used in IDMAC_SET_BUFFER1_SIZE such that they use only 13 bits instead of current 14. Signed-off-by: NShashidhar Hiremath <shashidharh@vayavyalabs.com> Acked-by: NWill Newton <will.newton@imgtec.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Michał Mirosław 提交于
Reported-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Kyungmin Park 提交于
The eMMC v4.5 Spec is released now: EXT_CSD_REV Extended CSD Revision 255-7 Reserved 6 Revision 1.6 (for MMC v4.5) 5 Revision 1.5 (for MMV v4.41) ... Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andy Shevchenko 提交于
During card removal and inserting cycle the test file in the debugfs could be stalled until the host driver removes it. Let's keep the file in the linked list and destroy it when card is removed. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NPer Forlin <per.forlin@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Jaehoon Chung 提交于
Samsung SoCs need to set BROKEN_ADMA_ZEROLEN_DESC. (If ADMA operation is more than 65535, maybe set by zero.) Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Philip Rakity 提交于
Enable the quirk. (Best used in conjunction with patch downgrading ADMA to SDMA when transfer is not aligned.) Signed-off-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Aaron Lu 提交于
Currently, the retuning timer for retuning mode 1 will be deleted in function sdhci_tasklet_finish after a mmc request done, which will make retuning timing never trigger again. This patch fixed this problem. Signed-off-by: NAaron Lu <Aaron.Lu@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 12 8月, 2011 5 次提交
-
-
由 Bruce Allan 提交于
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Bruce Allan 提交于
If word 0x37 in the EEPROM is 0xFFFF _or_ 0x0000, then there is no alternate MAC address in the EEPROM. Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Bruce Allan 提交于
Due to a hardware erratum, the receiver on 82574 and 82583 should not be stopped once it has been started. Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Bruce Allan 提交于
This issue is present all the way back to 2.6.34 kernels. CC: <stable@kernel.org> Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NJeffrey Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Julia Lawall 提交于
rs_resp is dynamically allocated in aem_read_sensor(), so it should be freed before exiting in every case. This collects the kfree and the return at the end of the function. Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com> Cc: stable@kernel.org # 2.6.27+
-