- 11 Mar, 2020 18 commits
-
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. Use using dma_request_chan() directly to return the real error code. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200227123749.24064-7-peter.ujfalusi@ti.com
-
Peter Ujfalusi authored
In case when DMA channel request or alloc_bam_transaction() fails, dma_unmap_single() and any channels already requested should be released. Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. Use using dma_request_chan() directly to return the real error code. Signed-off-by:
-
Peter Ujfalusi authored
Release the DMA channel on errors after the channel has been successfully requested. Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. Use using dma_request_chan() directly to return the real error code. Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Jonathan Neuschäfer authored
Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Frieder Schrempf authored
Currently when marking a block, we use spinand_erase_op() to erase the block before writing the marker to the OOB area. Doing so without waiting for the operation to finish can lead to the marking failing silently and no bad block marker being written to the flash. In fact we don't need to do an erase at all before writing the BBM. The ECC is disabled for raw accesses to the OOB data and we don't need to work around any issues with chips reporting ECC errors as it is known to be the case for raw NAND. Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
-
Frieder Schrempf authored
When writing the bad block marker to the OOB area the access mode should be set to MTD_OPS_RAW as it is done for reading the marker. Currently this only works because req.mode is initialized to MTD_OPS_PLACE_OOB (0) and spinand_write_to_cache_op() checks for req.mode != MTD_OPS_AUTO_OOB. Fix this by explicitly setting req.mode to MTD_OPS_RAW. Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs") Signed-off-by:
-
Frieder Schrempf authored
For reading and writing the bad block markers, spinand->oobbuf is currently used as a buffer for the marker bytes. During the underlying read and write operations to actually get/set the content of the OOB area, the content of spinand->oobbuf is reused and changed by accessing it through spinand->oobbuf and/or spinand->databuf. This is a flaw in the original design of the SPI NAND core and at the latest from 13c15e07 ("mtd: spinand: Handle the case where PROGRAM LOAD does not reset the cache") on, it results in not having the bad block marker written at all, as the spinand->oobbuf is cleared to 0xff after setting the marker bytes to zero. To fix it, we now just store the two bytes for the marker on the stack and let the read/write operations copy it from/to the page buffer later. Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by:
-
Mason Yang authored
Document the bindings used by the Macronix NAND device. Signed-off-by:
Mason Yang <masonccyang@mxic.com.tw> Reviewed-by:
Rob Herring <robh@kernel.org> [<miquel.raynal@bootlin.com: Fix typos] Signed-off-by:
-
Mason Yang authored
Macronix NANDs support randomizer operation for user data scrambled, which can be enabled with a SET_FEATURE. User data written to the NAND device without randomizer is still readable after randomizer function enabled. The penalty of randomizer are subpage accesses prohibited and more time period is needed in program operation and entering deep power-down mode. i.e., tPROG 300us to 340us(randomizer enabled) For more high-reliability concern, if subpage write not available with hardware ECC and then to enable randomizer is recommended by default. Driver checks byte 167 of Vendor Blocks in ONFI parameter page table to see if this high-reliability function is supported. By adding a new specific DT property in children nodes to enable randomizer function. Signed-off-by:
-
Janusz Krzysztofik authored
Another step in preparation for merging the driver with "gpio-nand". Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
-
Janusz Krzysztofik authored
In order to be merged with "gpio-nand", the driver must support custom (non-GPIO) I/O accessors. Allow platforms to omit data GPIO port as well as NWE pin info from device setup. For the driver to still work on such platform, custom I/O accessors as well as a custom probe function which initialises the driver private structure with those accessors must be added to the driver. Signed-off-by:
-
Janusz Krzysztofik authored
For consistency with adjacent code patterns used in the driver probe function, store data GPIO array pointer directly in a respective field of the driver private structure instead of storing it intermediately in a local variable for error checking. Signed-off-by:
-
Janusz Krzysztofik authored
In preparation for extending the driver with custom I/O support, try to obtain device specific initialisation routine from a matching device table entry and run it as an additional step of device probe. Signed-off-by:
-
Janusz Krzysztofik authored
In preparation for merging the driver with "gpio-nand", introduce module device tables where new device models can be accommodated as soon as respective support is added. Signed-off-by:
-
- 09 Mar, 2020 15 commits
-
-
Janusz Krzysztofik authored
In order to make the driver more useful on platforms other than Amstrad Delta, allow GPIO descriptor pointers of possibly non-critical NWP and NCE pins to be initialised as NULL. Signed-off-by:
-
Janusz Krzysztofik authored
Allow platforms to omit NRE pin from device configuration by requesting that pin as optional. In that case, also don't apply read pulse width from chip SDR timings. There should be no need for further code adjustments as gpiolib can handle NULL GPIO descriptor pointers. Signed-off-by:
-
Janusz Krzysztofik authored
Instead of forcing Amstrad Delta specific read/write pulse widths, use variables initialised from respective fields of chip SDR timings. Signed-off-by:
-
Janusz Krzysztofik authored
Let platforms take care of declaring correct GPIO pin polarity so we can just ask a GPIO line to be asserted or deasserted and gpiolib deals with the rest depending on how the platform is configured. Inspired by similar changes to regulator drivers by Linus Walleij <linus.walleij@linaro.org>, thanks! Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Janusz Krzysztofik authored
Provide MTD layer with device OF node info required by OF partition parser. Signed-off-by:
-
Janusz Krzysztofik authored
Now as we support fetching partition info from device platform data and the Amstrad Delta board file provides that info, drop it from the driver code. v2: rebase on top of gpio_nand_platdata extension Signed-off-by:
-
Janusz Krzysztofik authored
Now as the Amstrad Delta NAND driver supports fetching information on MTD partitions from device platform data, add partition info to the NAND device configuration. Signed-off-by:
-
Janusz Krzysztofik authored
In order to be able to move the hardcoded Amstrad Delta partition info from the driver code to the board file, reuse gpio_nand_platdata structure owned by "gpio-nand" driver and try to obtain information on device partitions from device platform data. Signed-off-by:
-
Janusz Krzysztofik authored
Initialise NWP GPIO pin as asserted to protect the device from hazard during setup of other GPIO pins. Signed-off-by:
-
Paul Cercueil authored
Use devm_platform_ioremap_resource() instead of platform_get_resource() + devm_ioremap_resource(). Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Chuanhong Guo authored
Currently there are 3 different variants of read_id implementation: 1. opcode only. Found in GD5FxGQ4xF. 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E 3. opcode + 1 dummy byte. Found in other currently supported chips. Original implementation was for variant 1 and let detect function of chips with variant 2 and 3 to ignore the first byte. This isn't robust: 1. For chips of variant 2, if SPI master doesn't keep MOSI low during read, chip will get a random id offset, and the entire id buffer will shift by that offset, causing detect failure. 2. For chips of variant 1, if it happens to get a devid that equals to manufacture id of variant 2 or 3 chips, it'll get incorrectly detected. This patch reworks detect procedure to address problems above. New logic do detection for all variants separatedly, in 1-2-3 order. Since all current detect methods do exactly the same id matching procedure, unify them into core.c and remove detect method from manufacture_ops. Tested on GD5F1GQ4UAYIG and W25N01GVZEIG. Signed-off-by:
Chuanhong Guo <gch981213@gmail.com> Signed-off-by:
-
Yoshio Furuyama authored
Add a comment above NAND_MFR_TOSHIBA and SPINAND_MFR_TOSHIBA definitions that Toshiba and Kioxia ID are the same. Since its independence from Toshiba Group, Toshiba memory Co has become Kioxia Co. Signed-off-by:
Yoshio Furuyama <ytc-mb-yfuruyama7@kioxia.com> Signed-off-by:
-
Masahiro Yamada authored
If the write protect signal from this IP is connected to the NAND device, this IP can handle the WP# pin via the WRITE_PROTECT register. The Denali NAND Flash Memory Controller User's Guide describes this register like follows: When the controller is in reset, the WP# pin is always asserted to the device. Once the reset is removed, the WP# is de-asserted. The software will then have to come and program this bit to assert/de-assert the same. 1 - Write protect de-assert 0 - Write protect assert The default value is 1, so the write protect is de-asserted after the reset is removed. The driver can write to the device unless someone has explicitly cleared register before booting the kernel. The boot ROM of some UniPhier SoCs (LD4, Pro4, sLD8, Pro5) is the case; the boot ROM clears the WRITE_PROTECT register when the system is booting from the NAND device, so the NAND device becomes read-only. Set it to 1 in the driver in order to allow the write access to the device. Signed-off-by: -
Christophe Kerello authored
This patch releases the resources allocated in nanddev_init function. Fixes: a7ab085d ("mtd: rawnand: Initialize the nand_device object") Signed-off-by:
Christophe Kerello <christophe.kerello@st.com> Signed-off-by:
-
Martin Devera authored
The used way to compute jiffies timeout brokes when jiffie difference is 1. Assume that nand_soft_waitrdy is called with timeout_ms==1. Jiffies are 1000 for example (assume something more like 1000.99 - just before incrementing to 1001). We compute timeout_ms = 1000+msecs_to_jiffies(1) = 1001. nand_read_data_op is called for the first time and returns 0. During the call jiffies changes to 1001 thus "while loop" ends here (wrongly). Notice that routine was called with expected timeout 1ms but actual timeout used was something between 0...1ms. Fixes STM32MP1 FMC2 NAND controller which sometimes failed exactly in this way. Signed-off-by:
Martin Devera <devik@eaxlabs.cz> Signed-off-by:
-
- 01 Mar, 2020 5 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4Linus Torvalds authored
Pull ext4 fixes from Ted Ts'o: "Two more bug fixes (including a regression) for 5.6" * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() jbd2: fix data races at struct journal_head
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull KVM fixes from Paolo Bonzini: "More bugfixes, including a few remaining "make W=1" issues such as too large frame sizes on some configurations. On the ARM side, the compiler was messing up shadow stacks between EL1 and EL2 code, which is easily fixed with __always_inline" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: VMX: check descriptor table exits on instruction emulation kvm: x86: Limit the number of "kvm: disabled by bios" messages KVM: x86: avoid useless copy of cpufreq policy KVM: allow disabling -Werror KVM: x86: allow compiling as non-module with W=1 KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis KVM: Introduce pv check helpers KVM: let declaration of kvm_get_running_vcpus match implementation KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter arm64: Ask the compiler to __always_inline functions used by KVM at HYP KVM: arm64: Define our own swab32() to avoid a uapi static inline KVM: arm64: Ask the compiler to __always_inline functions used at HYP kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe() KVM: arm/arm64: Fix up includes for trace.h
-
Oliver Upton authored
KVM emulates UMIP on hardware that doesn't support it by setting the 'descriptor table exiting' VM-execution control and performing instruction emulation. When running nested, this emulation is broken as KVM refuses to emulate L2 instructions by default. Correct this regression by allowing the emulation of descriptor table instructions if L1 hasn't requested 'descriptor table exiting'. Fixes: 07721fee ("KVM: nVMX: Don't emulate instructions in guest mode") Reported-by:
Jan Kiszka <jan.kiszka@web.de> Cc: stable@vger.kernel.org Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Jim Mattson <jmattson@google.com> Signed-off-by:
Oliver Upton <oupton@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "I2C has three driver bugfixes for you. We agreed on the Mac regression to go in via I2C" * 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: macintosh: therm_windtunnel: fix regression when instantiating devices i2c: altera: Fix potential integer overflow i2c: jz4780: silence log flood on txabrt
-
- 29 Feb, 2020 2 commits
-
-
Dan Carpenter authored
If sbi->s_flex_groups_allocated is zero and the first allocation fails then this code will crash. The problem is that "i--" will set "i" to -1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1 is type promoted to unsigned and becomes UINT_MAX. Since UINT_MAX is more than zero, the condition is true so we call kvfree(new_groups[-1]). The loop will carry on freeing invalid memory until it crashes. Fixes: 7c990728 ("ext4: fix potential race between s_flex_groups online resizing and access") Reviewed-by:
Suraj Jitindar Singh <surajjs@amazon.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Link: https://lore.kernel.org/r/20200228092142.7irbc44yaz3by7nb@kili.mountainSigned-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Wolfram Sang authored
Removing attach_adapter from this driver caused a regression for at least some machines. Those machines had the sensors described in their DT, too, so they didn't need manual creation of the sensor devices. The old code worked, though, because manual creation came first. Creation of DT devices then failed later and caused error logs, but the sensors worked nonetheless because of the manually created devices. When removing attach_adaper, manual creation now comes later and loses the race. The sensor devices were already registered via DT, yet with another binding, so the driver could not be bound to it. This fix refactors the code to remove the race and only manually creates devices if there are no DT nodes present. Also, the DT binding is updated to match both, the DT and manually created devices. Because we don't know which device creation will be used at runtime, the code to start the kthread is moved to do_probe() which will be called by both methods. Fixes: 3e7bed52 ("macintosh: therm_windtunnel: drop using attach_adapter") Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723Reported-by:
Erhard Furtner <erhard_f@mailbox.org> Tested-by:
Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org # v4.19+
-
