- 09 Oct, 2019 7 commits
-
-
Navid Emamdoost authored
In adis_update_scan_mode, if allocation for adis->buffer fails, previously allocated adis->xfer needs to be released. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Fabrice Gasnier authored
End of conversion may be handled by using IRQ or DMA. There may be a race when two conversions complete at the same time on several ADCs. EOC can be read as 'set' for several ADCs, with: - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally called in this case. - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA request instead. It's then automatically cleared by DMA read. But the handler gets called due to status bit is temporarily set (IRQ triggered by the other ADC). So both EOC status bit in CSR and EOCIE control bit must be checked before invoking the interrupt handler (e.g. call ISR only for IRQ-enabled ADCs). Fixes: 2763ea05 ("iio: adc: stm32: add optional dma support") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Fabrice Gasnier authored
Move STM32 ADC registers definitions to common header. This is precursor patch to: - iio: adc: stm32-adc: fix a race when using several adcs with dma and irq It keeps registers definitions as a whole block, to ease readability and allow simple access path to EOC bits (readl) in stm32-adc-core driver. Fixes: 2763ea05 ("iio: adc: stm32: add optional dma support") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stefan Popa authored
We need to perform a reset a start up to make sure that the chip is in a consistent state. This reset also disables all the interrupts which should only be enabled together with the iio buffer. Not doing this, was sometimes causing unwanted interrupts to trigger. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Fixes: f4f55ce3 ("iio:adxl372: Add FIFO and interrupts support") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stefan Popa authored
One in two sample sets was lost by multiplying fifo_set_size with sizeof(u16). Also, the double number of available samples were pushed to the iio buffers. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Fixes: f4f55ce3 ("iio:adxl372: Add FIFO and interrupts support") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Stefan Popa authored
Currently, the driver sets the FIFO_SAMPLES register with the number of sample sets (maximum of 170 for 3 axis data, 256 for 2-axis and 512 for single axis). However, the FIFO_SAMPLES register should store the number of samples, regardless of how the FIFO format is configured. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Fixes: f4f55ce3 ("iio:adxl372: Add FIFO and interrupts support") Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andreas Klinger authored
Fix bug in sampling function hx711_cycle() when interrupt occures while PD_SCK is high. If PD_SCK is high for at least 60 us power down mode of the sensor is entered which in turn leads to a wrong measurement. Switch off interrupts during a PD_SCK high period and move query of DOUT to the latest point of time which is at the end of PD_SCK low period. This bug exists in the driver since it's initial addition. The more interrupts on the system the higher is the probability that it happens. Fixes: c3b2fdd0 ("iio: adc: hx711: Add IIO driver for AVIA HX711") Signed-off-by: Andreas Klinger <ak@it-klinger.de> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 08 Sep, 2019 3 commits
-
-
Pascal Bouwmann authored
The center temperature of the supported devices stored in the constant BMC150_ACCEL_TEMP_CENTER_VAL is not 24 degrees but 23 degrees. It seems that some datasheets were inconsistent on this value leading to the error. For most usecases will only make minor difference so not queued for stable. Signed-off-by: Pascal Bouwmann <bouwmann@tau-tec.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Lorenzo Bianconi authored
Do not allow configuring null sensor gain since it will force to 0 device outputs Fixes: c8d4066c7246 ("iio: imu: st_lsm6dsx: remove invalid gain value for LSM9DS1") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Remi Pommarel authored
meson_saradc's irq handler uses priv->regmap so make sure that it is allocated before the irq get enabled. This also fixes crash when CONFIG_DEBUG_SHIRQ is enabled, as device managed resources are freed in the inverted order they had been allocated, priv->regmap was freed before the spurious fake irq that CONFIG_DEBUG_SHIRQ adds called the handler. Fixes: 3af10913 ("iio: adc: meson-saradc: switch from polling to interrupt mode") Reported-by: Elie Roudninski <xademax@gmail.com> Signed-off-by: Remi Pommarel <repk@triplefau.lt> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: Elie ROUDNINSKI <xademax@gmail.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 06 Sep, 2019 5 commits
-
-
Colin Ian King authored
The variable n is being assigned a value that is never read inside an if statement block, the assignment is redundant and can be removed. With this removed, n is only being used for a constant loop bounds check, so replace n with that value instead and remove n completely. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20190905152227.4610-1-colin.king@canonical.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rohit Sarkar authored
Fixes a typo in the documentation. Signed-off-by: Rohit Sarkar <rohitsarkar5398@gmail.com> Link: https://lore.kernel.org/r/20190905132219.GA1004@SARKARSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
time_t suffers from overflow problems and should not be used. In exfat, it is currently used in two open-coded time64_to_tm() implementations. Changes those to use the existing function instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190906150917.1025250-2-arnd@arndb.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
When CONFIG_VFAT_FS is disabled, the reference to CONFIG_FAT_DEFAULT_IOCHARSET causes a link failure: drivers/staging/exfat/exfat_super.c:46:41: error: use of undeclared identifier 'CONFIG_FAT_DEFAULT_IOCHARSET' static char exfat_default_iocharset[] = CONFIG_FAT_DEFAULT_IOCHARSET; I could not figure out why the correct code is commented out, but using that fixes the problem. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190906150917.1025250-1-arnd@arndb.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andy Shevchenko authored
The commit 473d12f7 ("iio: hid-sensor-attributes: Convert to use int_pow()") converted to use generic int_pow() helper. Though, the generic one returns 64-bit value and, in cases when it is used as divisor, it compels 64-bit division from compiler. In order to fix this, introduce a temporary 32-bit variable to hold the result of int_pow() and use it as divisor afterwards. In couple of cases, replace int_pow() with a predefined unit factors for time and frequency. Fixes: 473d12f7 ("iio: hid-sensor-attributes: Convert to use int_pow()") Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20190905112759.13035-1-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 05 Sep, 2019 25 commits
-
-
Gao Xiang authored
As Christoph said [1], "I'd much prefer to just use read_cache_page_gfp, and live with the fact that this allocates bufferheads behind you for now. I'll try to speed up my attempts to get rid of the buffer heads on the block device mapping instead. " This simplifies the code a lot and a minor thing is "no REQ_META (e.g. for blktrace) on metadata at all..." [1] https://lore.kernel.org/r/20190903153704.GA2201@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-26-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said [1] [2], "Just use the slightly more complicated 32-bit version everywhere so that you have a single actually tested code path. And then remove this helper. " [1] https://lore.kernel.org/r/20190829102426.GE20598@infradead.org/ [2] https://lore.kernel.org/r/20190902125320.GA16726@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-25-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said [1], "This seems to be your only direct use of buffer heads, which while not deprecated are a bit of an ugly step child. So if you can easily avoid creating a buffer_head dependency in a new filesystem I think you should avoid it. " [1] https://lore.kernel.org/r/20190902125109.GA9826@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-24-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
Add prefix "erofs_" to these functions and print sb->s_id as a prefix to erofs_{err, info} so that the user knows which file system is affected. Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-23-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said [1], ".. and save one level of indentation." [1] https://lore.kernel.org/r/20190829102426.GE20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-22-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said [1], "vm_map_ram is supposed to generally behave better. So if it doesn't please report that that to the arch maintainer and linux-mm so that they can look into the issue. Having user make choices of deep down kernel internals is just a horrible interface. Please talk to maintainers of other bits of the kernel if you see issues and / or need enhancements. " Let's redo the previous conclusion and kill the vmap approach. [1] https://lore.kernel.org/r/20190830165533.GA10909@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-21-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph suggested [1], "Please just use plain kmalloc everywhere and let the normal kernel error injection code take care of injeting any errors." [1] https://lore.kernel.org/r/20190829102426.GE20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-20-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
Add erofs_ prefix to free_inode, alloc_inode, ... Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-19-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph pointed out [1], " Why is there __submit_bio which really just obsfucates what is going on? Also why is __submit_bio using bio_set_op_attrs instead of opencode it as the comment right next to it asks you to? " Let's use submit_bio directly instead. [1] https://lore.kernel.org/r/20190830162812.GA10694@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-18-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph pointed out [1], "Why is there __erofs_get_meta_page with the two weird booleans instead of a single erofs_get_meta_page that gets and gfp_t for additional flags and an unsigned int for additional bio op flags." And since all callers can handle errors, let's kill prio and nofail and erofs_get_inline_page() now. [1] https://lore.kernel.org/r/20190830162812.GA10694@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-17-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph pointed out [1], "erofs_grab_bio tries to handle a bio_alloc failure, except that the function will not actually fail due the mempool backing it." Sorry about useless code, fix it now and localize erofs_grab_bio [2]. [1] https://lore.kernel.org/r/20190830162812.GA10694@infradead.org/ [2] https://lore.kernel.org/r/20190902122016.GL15931@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-16-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said [1], "That is some very verbose debug info. We usually don't add that and let people trace the function instead. " [1] https://lore.kernel.org/r/20190829101545.GC20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-15-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph pointed out [1], "Why is the variable name for the on-disk subperblock layout? We usually still calls this something with sb in the name, e.g. dsb. for disksuper block. " Let's fix it. [1] https://lore.kernel.org/r/20190829101545.GC20598@infradead.org/Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-14-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
Fix as Christoph suggested [1] [2], "remove is_inode_fast_symlink and just opencode it in the few places using it" and "Please just set the ops directly instead of obsfucating that in a single caller, single line inline function. And please set it instead of the normal symlink iops in the same place where you also set those." [1] https://lore.kernel.org/r/20190830163910.GB29603@infradead.org/ [2] https://lore.kernel.org/r/20190829102426.GE20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-13-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph suggested [1], update them all. [1] https://lore.kernel.org/r/20190829102426.GE20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-12-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said [1] [2], update it now. [1] https://lore.kernel.org/r/20190902124521.GA22153@infradead.org/ [2] https://lore.kernel.org/r/20190902120548.GB15931@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-11-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph suggested [1], "Why is this called vnode instead of inode? That seems like a rather odd naming for a Linux file system." [1] https://lore.kernel.org/r/20190829101545.GC20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-10-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said [1] "having this function seems entirely pointless", let's kill those. filesystem function name ext2,f2fs,ext4,isofs,squashfs,cifs,... init_inodecache In addition, add a necessary "rcu_barrier()" on exit_fs(); [1] https://lore.kernel.org/r/20190829101545.GC20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-9-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
updates inode naming - kill is_inode_layout_compression [1] - kill magic underscores [2] [3] - better naming for datamode & data_mapping_mode [3] - better naming erofs_inode_{compact, extended} [4] [1] https://lore.kernel.org/r/20190829102426.GE20598@infradead.org/ [2] https://lore.kernel.org/r/20190829102426.GE20598@infradead.org/ [3] https://lore.kernel.org/r/20190902122627.GN15931@infradead.org/ [4] https://lore.kernel.org/r/20190902125438.GA17750@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-8-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said [1], "This is only cosmetic, why not stick to feature_compat and feature_incompat?" In my thought, requirements means "incompatible" instead of "feature" though. [1] https://lore.kernel.org/r/20190902125109.GA9826@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-7-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph said, "This looks like a really obsfucated way to write: return datamode == EROFS_INODE_FLAT_COMPRESSION || datamode == EROFS_INODE_FLAT_COMPRESSION_LEGACY; " Although I had my own consideration, it's the right way for now. [1] https://lore.kernel.org/r/20190829095954.GB20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-6-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph suggested "Please don't add __packed" [1], remove all __packed except struct erofs_dirent here. Note that all on-disk fields except struct erofs_dirent (12 bytes with a 8-byte nid) in EROFS are naturally aligned. [1] https://lore.kernel.org/r/20190829095954.GB20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-5-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph suggested [1], these macros are much more readable as a function. [1] https://lore.kernel.org/r/20190829095954.GB20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-4-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph suggested [1], on-disk format should have explicitly assigned numbers. [1] https://lore.kernel.org/r/20190829095954.GB20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-3-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gao Xiang authored
As Christoph suggested [1], "Please remove all the byte offset comments. that is something that can easily be checked with gdb or pahole." [1] https://lore.kernel.org/r/20190829095954.GB20598@infradead.org/Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Link: https://lore.kernel.org/r/20190904020912.63925-2-gaoxiang25@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-