[ Upstream commit 5c498950f730aa17c5f8a2cdcb903524e4002ed2 ]
Signed-off-by: Luis Henriques
Reviewed-by: Jeff Layton
Signed-off-by: Ilya Dryomov
Signed-off-by: Sasha Levin
---
include/linux/ceph/buffer.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
[ Upstream commit cfef46d692efd852a0da6803f920cc756eea2855 ]
When a Tx timestamp is requested, a pointer to the skb is stored in the
ravb_tstamp_skb struct. This was done without an skb_get. There exists
the possibility that the skb could be freed by ravb_tx_free (when
ravb_tx_free is called from
[ Upstream commit 5c1baaa82cea2c815a5180ded402a7cd455d1810 ]
In mlx4_ib_alloc_pv_bufs(), 'tun_qp->tx_ring' is allocated through
kcalloc(). However, it is not always deallocated in the following execution
if an error occurs, leading to memory leaks. To fix this issue, free
'tun_qp->tx_ring'
[ Upstream commit af8a85a41734f37b67ba8ce69d56b685bee4ac48 ]
Calling ceph_buffer_put() in fill_inode() may result in freeing the
i_xattrs.blob buffer while holding the i_ceph_lock. This can be fixed by
postponing the call until later, when the lock is released.
The following backtrace was
[ Upstream commit 5c498950f730aa17c5f8a2cdcb903524e4002ed2 ]
Signed-off-by: Luis Henriques
Reviewed-by: Jeff Layton
Signed-off-by: Ilya Dryomov
Signed-off-by: Sasha Levin
---
include/linux/ceph/buffer.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
[ Upstream commit c554336efa9bbc28d6ec14efbee3c7d63c61a34f ]
In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails,
leading to a memory leak bug. To fix this issue, free t before returning
the error.
Signed-off-by: Wenwen Wang
Signed-off-by: David S. Miller
Signed-off-by:
[ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for
[ Upstream commit 66cf4710b23ab2adda11155684a2c8826f4fe732 ]
The ibm,mac-address-filters property defines the maximum number of
addresses the hypervisor's multicast filter list can support. It is
encoded as a big-endian integer in the OF device tree, but the virtual
ethernet driver does not
[ Upstream commit 86968ef21596515958d5f0a40233d02be78ecec0 ]
Calling ceph_buffer_put() in __ceph_setxattr() may end up freeing the
i_xattrs.prealloc_blob buffer while holding the i_ceph_lock. This can be
fixed by postponing the call until later, when the lock is released.
The following
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]
clang warns:
drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&&' with constant operand [-Wconstant-logical-operand]
if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
[ Upstream commit 8c25d0887a8bd0e1ca2074ac0c6dff173787a83b ]
As spin_unlock_irq will enable interrupts.
Function tsi108_stat_carry is called from interrupt handler tsi108_irq.
Interrupts are enabled in interrupt handler.
Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_(un)lock_irq
in
[ Upstream commit 20fb7c7a39b5c719e2e619673b5f5729ee7d2306 ]
In myri10ge_probe(), myri10ge_alloc_slices() is invoked to allocate slices
related structures. Later on, myri10ge_request_irq() is used to get an irq.
However, if this process fails, the allocated slices related structures are
not
[ Upstream commit 89eb4d8d25722a0a0194cf7fa47ba602e32a6da7 ]
When building hv_kvp_daemon GCC-8.3 complains:
hv_kvp_daemon.c: In function ‘kvp_get_ip_info.constprop’:
hv_kvp_daemon.c:812:30: warning: ‘ip_buffer’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
struct
[ Upstream commit 68e03b85474a51ec1921b4d13204782594ef7223 ]
when do randbuilding, I got this error:
In file included from drivers/hwmon/pmbus/ucd9000.c:19:0:
./include/linux/gpio/driver.h:576:1: error: redefinition of
gpiochip_add_pin_range
gpiochip_add_pin_range(struct gpio_chip *chip, const
[ Upstream commit 44ef3a03252844a8753479b0cea7f29e4a804bdc ]
In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
to hold the original command line options. Then, the options are parsed.
However, if an error occurs during the parsing process, 'options_orig' is
not
[ Upstream commit 1eca92eef18719027d394bf1a2d276f43e7cf886 ]
In cx82310_bind(), 'dev->partial_data' is allocated through kmalloc().
Then, the execution waits for the firmware to become ready. If the firmware
is not ready in time, the execution is terminated. However, the allocated
[ Upstream commit 5c1baaa82cea2c815a5180ded402a7cd455d1810 ]
In mlx4_ib_alloc_pv_bufs(), 'tun_qp->tx_ring' is allocated through
kcalloc(). However, it is not always deallocated in the following execution
if an error occurs, leading to memory leaks. To fix this issue, free
'tun_qp->tx_ring'
[ Upstream commit cfef46d692efd852a0da6803f920cc756eea2855 ]
When a Tx timestamp is requested, a pointer to the skb is stored in the
ravb_tstamp_skb struct. This was done without an skb_get. There exists
the possibility that the skb could be freed by ravb_tx_free (when
ravb_tx_free is called from
Reading /sys/class/leds//trigger returns all available LED triggers.
However, this violates the "one value per file" rule of sysfs.
This provides /sys/class/leds//current-trigger which is almost
identical to /sys/class/leds//trigger. The only difference is that
'current-trigger' only shows the
Reading /sys/class/leds//trigger returns all available LED triggers.
However, this violates the "one value per file" rule of sysfs.
This provides /sys/class/leds/triggers directory that contains a number of
sub-directories, each representing an LED trigger. The name of the
sub-directory matches
If the led-class and usb-common modules are built into the kernel, the
usb-common module could be initialized earlier than the led-class module.
So when the ledtrig_usb_gadget and ledtrig_usb_host LED triggers are
registered by usb-common module, the leds_class could not be initialized
yet.
We
Reading /sys/class/leds//trigger returns all available LED triggers.
However, the size of this file is limited to PAGE_SIZE because of the
limitation for sysfs attribute.
Enabling LED CPU trigger on systems with thousands of CPUs easily hits
PAGE_SIZE limit, and makes it impossible to see all
This adds a new function class_kobject_create_and_add() that creates a
directory in the /sys/class/.
This function is required to create the /sys/class/leds/triggers directory
that contains all available LED triggers.
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Jacek Anaszewski
Cc:
Reading /sys/class/leds//trigger returns all available LED triggers.
However, the size of this file is limited to PAGE_SIZE because of the
limitation for sysfs attribute.
Enabling LED CPU trigger on systems with thousands of CPUs easily hits
PAGE_SIZE limit, and makes it impossible to see all
syzbot has bisected this bug to:
commit e0a7683d30e91e30ee6cf96314ae58a0314a095e
Author: Leandro Dorileo
Date: Mon Apr 8 17:12:18 2019 +
net/sched: cbs: fix port_rate miscalculation
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=158f3c0160
start commit: 3b47fd5c
On Sat, 7 Sep 2019 11:20:07 +0200
Krzysztof Kozlowski wrote:
> Commit fafb37cfae6d ("iio: exyno-adc: use syscon for PMU
> register access") changed the Exynos ADC driver so the PMU syscon
> phandle is required instead of second register address space. The
> bindings were not updated so fix
On Sat, 7 Sep 2019 11:20:06 +0200
Krzysztof Kozlowski wrote:
> Convert Samsung Exynos Analog to Digital Converter bindings to DT schema
> format using json-schema.
>
> This is a direct conversion of existing bindings so it also copies the
> existing error in the bindings regarding the
On Sat, 27 Jul 2019 21:59:40 +0200
Artur Rojek wrote:
> Add support for the ADC hardware present on Ingenic JZ4770 SoC.
>
> Signed-off-by: Artur Rojek
> Tested-by: Paul Cercueil
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
On Sat, 27 Jul 2019 21:59:39 +0200
Artur Rojek wrote:
> Introduce support for AUX2 channel found in ADC hardware present on
> Ingenic JZ4770 SoC.
>
> Signed-off-by: Artur Rojek
> Reviewed-by: Rob Herring
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to
On Tue, 03 Sep 2019 21:09:24 +0200
Artur Rojek wrote:
> Hi Jonathan,
>
> Just reminding you of this patch set.
>
> Artur
Hi Artur,
Thanks for the reminder. As you'd no doubt concluded, I'd
dropped it down the back of the sofa.
Unfortunately it's now just missed my last pull for 5.4
On 06-09-19, 17:18, Peter Ujfalusi wrote:
> In case the channel is not requested via the slave API, use the
> of_find_dma_domain() to see if a system default DMA controller is
> specified.
>
> Add new function which can be used by clients to request channels by mask
> from their DMA domain
On Fri, Sep 06, 2019 at 10:45:31PM +, Dexuan Cui wrote:
From: Sasha Levin
Sent: Friday, September 6, 2019 1:03 PM
On Thu, Sep 05, 2019 at 11:01:14PM +, Dexuan Cui wrote:
>This patchset (consisting of 9 patches) was part of the v4 patchset (consisting
>of 12 patches):
>
>The other 3
On 06-09-19, 17:18, Peter Ujfalusi wrote:
> Find the DMA domain controller of the client device by iterating up in
> device tree looking for the closest 'dma-domain-controller' property.
>
> If the client's node is not provided then check the DT root for the
> controller.
>
> Signed-off-by:
On 08-09-19, 10:47, Peter Ujfalusi wrote:
>
>
> On 06/09/2019 17.18, Peter Ujfalusi wrote:
> > On systems where multiple DMA controllers available, none Slave (for example
> > memcpy operation) users can not be described in DT as there is no device
> > involved from the DMA controller's point of
On 06-09-19, 17:18, Peter Ujfalusi wrote:
> On systems where multiple DMA controllers available, none Slave (for example
On systems with multiple DMA controllers, non Slave...
> memcpy operation) users can not be described in DT as there is no device
> involved from the DMA controller's point of
Function ftrace_lookup_ip() will check empty hash table. So we don't
need extra check outside.
Signed-off-by: Changbin Du
---
kernel/trace/ftrace.c | 15 ---
kernel/trace/trace.h | 6 --
2 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/kernel/trace/ftrace.c
On 2019/9/6 19:52, Miklos Szeredi wrote:
> On Fri, Sep 6, 2019 at 12:36 PM Stefan Hajnoczi wrote:
>>
>> On Fri, Sep 06, 2019 at 10:15:14AM +0200, Miklos Szeredi wrote:
>>> On Thu, Sep 5, 2019 at 9:49 PM Vivek Goyal wrote:
Hi,
Michael Tsirkin pointed out issues w.r.t
On 6 Sep 2019, at 16:50, Chuck Lever wrote:
On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III
wrote:
"JBF" == J Bruce Fields writes:
JBF> Those readdir changes were client-side, right? Based on that
I'd
JBF> been assuming a client bug, but maybe it'd be worth getting a
full
JBF>
On Sun, 1 Sep 2019 16:27:49 +0100
Colin King wrote:
> From: Colin Ian King
>
> Variable ret is being assigned a value that is never read and
> is being re-assigned a little later on. The assignment is redundant
> and hence can be removed.
>
> Addresses-Coverity: ("Ununsed value")
>
On Mon, 2 Sep 2019 21:40:49 +0100
Elie Roudninski wrote:
> On Sun, Sep 1, 2019 at 12:29 PM Martin Blumenstingl
> wrote:
> >
> > On Sun, Sep 1, 2019 at 12:45 PM Remi Pommarel wrote:
> > >
> > > meson_saradc's irq handler uses priv->regmap so make sure that it is
> > > allocated before the irq
On Sun, 8 Sep 2019 09:20:16 +0100
Toke Høiland-Jørgensen wrote:
> syzbot found a crash in dev_map_hash_update_elem(), when replacing an
> element with a new one. Jesper correctly identified the cause of the crash
> as a race condition between the initial lookup in the map (which is done
>
On 2019/9/6 3:48, Vivek Goyal wrote:
> It is possible that a mount is in progress and device is being removed at
> the same time. Use virtio_fs_mutex to avoid races.
>
> This also takes care of bunch of races and removes some TODO items.
>
> Signed-off-by: Vivek Goyal
> ---
>
On Mon, 2 Sep 2019 17:02:45 +0200
Thierry Reding wrote:
> On Sun, Sep 01, 2019 at 05:58:22PM -0500, David Lechner wrote:
> > The TI PWMSS driver is a simple bus driver for providing power
> > power management for the PWM peripherals on TI AM33xx SoCs, namely
> > eCAP, eHRPWM and eQEP. The eQEP
On Thu, 5 Sep 2019 07:10:53 -0700
Tony Lindgren wrote:
> * William Breathitt Gray [190905 13:38]:
> > On Sun, Sep 01, 2019 at 05:58:21PM -0500, David Lechner wrote:
> > > This series adds device tree bindings and a new counter driver for the
> > > Texas
> > > Instruments Enhanced Quadrature
On 2019/9/6 3:48, Vivek Goyal wrote:
> This object is used both by fuse_connection as well virt device. So make
> this object reference counted and that makes it easy to define life cycle
> of the object.
>
> Now deivce can be removed while filesystem is still mounted. This will
> cleanup all
On Mon, 2 Sep 2019 13:26:02 +
"Ardelean, Alexandru" wrote:
> On Sun, 2019-09-01 at 21:59 -0300, Rodrigo Carvalho wrote:
> > Move ADIS16240 driver from staging to mainline.
> >
> > The ADIS16240 is a fully integrated digital shock detection
> > and recorder system.
>
>
> Hey,
>
>
On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote:
> This is a rework on the commit 7f466032dc9e ("vhost: access vq
> metadata through kernel virtual address").
>
> It was noticed that the copy_to/from_user() friends that was used to
> access virtqueue metdata tends to be very expensive
iovec addresses coming from vhost are assumed to be
pre-validated, but in fact can be speculated to a value
out of range.
Userspace address are later validated with array_index_nospec so we can
be sure kernel info does not leak through these addresses, but vhost
must also not leak userspace info
On Sat, Sep 07, 2019 at 02:13:22PM -0700, Linus Torvalds wrote:
On Sat, Sep 7, 2019 at 1:44 PM Thomas Gleixner wrote:
That's what I just replied to Chris. Can you do it right away or should I queue
it up?
Done.
I'd like to bring back a discussion we had last year on ksummit-discuss:
Hello!
trying to use zram block device, shows the following:
# zramctl -f -s 16g
# cat /sys/block/zram0/comp_algorithm
lzo [lzo-rle] lz4 lz4hc 842 zstd
# zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle16G 10.4M4K 112K 32
# mkfs.xfs
On Mon, 2 Sep 2019 14:14:18 -0300
Marcelo Schmitt wrote:
> Hi Rodrigo,
>
> This dt doc looks overal fine IMHO.
> I would just add some inline comments about the cpha and cpol
> properties.
>
> On 09/01, Rodrigo Carvalho wrote:
> > This patch add device tree binding documentation for ADIS16240.
Greg Kroah-Hartman writes:
> On Mon, Sep 02, 2019 at 03:00:17PM -0400, Valdis Klētnieks wrote:
>> On Mon, 02 Sep 2019 17:25:24 +0200, Greg Kroah-Hartman said:
>>
>> > I dug up my old discussion with the current vfat maintainer and he said
>> > something to the affect of, "leave the existing
On Mon, 2 Sep 2019 13:31:32 +0200
Krzysztof Wilczynski wrote:
> Move the static keyword to the front of declaration of
> bh1750_chip_info_tbl, and resolve the following compiler
> warning that can be seen when building with warnings
> enabled (W=1):
>
> drivers/iio/light/bh1750.c:64:1:
On Mon, 2 Sep 2019 16:08:28 +0300
Mircea Caprioru wrote:
> Add initial ABI documentation for ad7192 adc sysfs interfaces.
>
> Signed-off-by: Mircea Caprioru
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to ignore ;)
Thanks,
Jonathan
> ---
> Changelog
On Mon, 2 Sep 2019 16:08:30 +0300
Mircea Caprioru wrote:
> This patch will add a system calibration attribute for each channel. Using
> this option the user will have the ability to calibrate each channel for
> zero scale and full scale. It uses the iio_chan_spec_ext_info and IIO_ENUM
> to
On Mon, 2 Sep 2019 16:08:29 +0300
Mircea Caprioru wrote:
> This patch exports the ad_sd_calibrate function in order to be able to
> call it from outside ad_sigma_delta.
>
> There are cases where the option to calibrate one channel at a time is
> necessary (ex. system calibration for zero scale
On Tue, 3 Sep 2019 18:29:37 +0100
Rob Herring wrote:
> On Mon, 2 Sep 2019 16:08:31 +0300, Mircea Caprioru wrote:
> > This patch add device tree binding documentation for AD7192 adc in YAML
> > format.
> >
> > Signed-off-by: Mircea Caprioru
It seems that I messed up before and didn't actually
Naveen N. Rao's on September 6, 2019 4:20 am:
> Enable HAVE_FUNCTION_GRAPH_RET_ADDR_PTR for more robust stack unwinding
> when function graph tracer is in use. Convert powerpc show_stack() to
> use ftrace_graph_ret_addr() for better stack unwinding.
This series improved my case of a WARN_ON
Markus Elfring writes:
> From: Markus Elfring
> Date: Tue, 3 Sep 2019 14:56:16 +0200
>
> The brelse() function tests whether its argument is NULL
> and then returns immediately.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
>
Jan Stancek writes:
> sb_getblk does not guarantee that buffer_head is uptodate. If there is
> async read running in parallel for same buffer_head, it can overwrite
> just initialized msdos_dir_entry, leading to corruption:
> FAT-fs (loop0): error, corrupted directory (invalid entries)
>
On Tue, Sep 03, 2019 at 10:14:12AM +0200, Allan W. Nielsen wrote:
> The 09/03/2019 09:13, Ido Schimmel wrote:
> > On Mon, Sep 02, 2019 at 07:42:31PM +0200, Allan W. Nielsen wrote:
> > With these patches applied I assume I will see the following traffic
> > when running tcpdump on one of the
On Sun, Sep 08, 2019 at 04:04:39AM +, Nadav Amit wrote:
> > On Sep 7, 2019, at 9:47 PM, Greg Kroah-Hartman
> > wrote:
> >
> > On Tue, Aug 20, 2019 at 01:26:38PM -0700, Nadav Amit wrote:
> >> Francois reported that VMware balloon gets stuck after a balloon reset,
> >> when the VMCI doorbell
In cases when SDIO IRQs have been enabled, runtime suspend is prevented by
the driver. However, this still means msdc_runtime_suspend|resume() gets
called during system suspend/resume, via pm_runtime_force_suspend|resume().
This means during system suspend/resume, the register context of the
To make sure SDIO func drivers behaves correctly during system
suspend/resume, let add a WARN_ON in case the condition is a non-powered
SDIO card and there are some SDIO IRQs still being claimed.
Tested-by: Matthias Kaehlcke
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Ulf Hansson
---
From: Matthias Kaehlcke
To improve code quality, let's move the code that gets pending SDIO IRQs
from process_sdio_pending_irqs() into a dedicated function.
Signed-off-by: Matthias Kaehlcke
[Ulf: Converted function into static]
Tested-by: Matthias Kaehlcke
Signed-off-by: Ulf Hansson
---
The sdio_irq_pending flag is used to let host drivers indicate that it has
signaled an IRQ. If that is the case and we only have a single SDIO func
that have claimed an SDIO IRQ, our assumption is that we can avoid reading
the SDIO_CCCR_INTx register and just call the SDIO func irq handler
To avoid each host driver supporting SDIO IRQs, from keeping track
internally about if SDIO IRQs has been claimed, let's introduce a common
helper function, sdio_irq_claimed().
The function returns true if SDIO IRQs are claimed, via using the
information about the number of claimed irqs. This is
In cases when SDIO IRQs have been enabled, runtime suspend is prevented by
the driver. However, this still means dw_mci_runtime_suspend|resume() gets
called during system suspend/resume, via pm_runtime_force_suspend|resume().
This means during system suspend/resume, the register context of the
Instead of keeping track of whether SDIO IRQs have been enabled via an
internal sdhci status flag, avoid the open-coding and convert into using
sdio_irq_claimed().
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/sdhci.c | 7 +--
drivers/mmc/host/sdhci.h | 1 -
Nowadays sdhci prevents runtime suspend when SDIO IRQs are enabled.
However, some variants such as sdhci-esdhc-imx's, tries to allow runtime
suspend while having the SDIO IRQs enabled, but without supporting remote
wakeups. This support is a bit questionable, especially if the host device
have a
For the MMC_CAP2_SDIO_IRQ_NOTHREAD case and when using sdio_signal_irq(),
the ->ack_sdio_irq() is already mandatory, which was not the case for those
host drivers that called sdio_run_irqs() directly.
As there are no longer any drivers calling sdio_run_irqs(), let's clarify
the code by dropping
The sdhci_ack_sdio_irq() is called only when SDIO IRQs are enabled.
Therefore, let's drop the redundant check of the internal
SDHCI_SDIO_IRQ_ENABLED flag and just re-enable the IRQs immediately.
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Ulf Hansson
---
drivers/mmc/host/sdhci.c | 3 +--
1
System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using
MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile
behaviour. Some problems have been taken care of so far, but more issues
remains.
For example, calling the ->ack_sdio_irq() callback to let host
Changes in v2:
- Added reviewed/tested-by tags.
- Updated some changelogs.
- Renamed sdio_irq_enabled() to sdio_irq_claimed().
- Don't set sdio_irq_pending when resuming SDIO card, but just queue the
work.
The power management support for SDIO cards have
On 2019/9/6 3:48, Vivek Goyal wrote:
> When device is going away, drain all pending requests.
>
> Signed-off-by: Vivek Goyal
> ---
> fs/fuse/virtio_fs.c | 83 -
> 1 file changed, 51 insertions(+), 32 deletions(-)
>
> diff --git
On 9/7/19 2:18 PM, Andy Shevchenko wrote:
> On Fri, Sep 6, 2019 at 10:47 PM Srinivas Pandruvada
> wrote:
>>
>> On Fri, 2019-09-06 at 07:50 -0700, Srinivas Pandruvada wrote:
>>> On Fri, 2019-09-06 at 16:46 +0300, Andy Shevchenko wrote:
On Fri, Sep 06, 2019 at 05:39:54AM -0400, Prarit
Sorry, I have only now got round to working on this. It's not complete
yet but I have assimilated the feedback and converted subjective
phrases, like "I think..." into objective statements or put them in
TODO: so that someone else may verify. I have attached it to this
email.
Next step will be to
On Tue, 3 Sep 2019 12:19:11 +0300
Stefan Popa wrote:
> This patch disables the adxl372 interrupts at setup. The interrupts
> should be enabled together with the iio buffer. Not doing this, might
> cause an unwanted interrupt to trigger without being able to properly
> clear it.
>
>
On Tue, 3 Sep 2019 12:18:33 +0300
Stefan Popa wrote:
> 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
Looks right to me. Will pick up once we've
On Tue, 3 Sep 2019 12:18:07 +0300
Stefan Popa wrote:
> 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,
On Fri, 6 Sep 2019 at 23:30, Doug Anderson wrote:
>
> Hi,
>
> On Fri, Sep 6, 2019 at 2:20 AM Ulf Hansson wrote:
> >
> > On Fri, 6 Sep 2019 at 01:47, Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Sep 3, 2019 at 7:22 AM Ulf Hansson wrote:
> > > >
> > > > In the single SDIO IRQ handler
On Sun, 08 Sep 2019 09:09:47 +0100,
Linus Walleij wrote:
>
> On Fri, Sep 6, 2019 at 12:08 PM tip-bot2 for Marc Zyngier
> wrote:
>
> > The following commit has been merged into the irq/core branch of tip:
> >
> > Commit-ID: daa19fe5b082779962988a5ba9e38509004db3de
> > Gitweb:
> >
rtw_malloc prevents the use of kmemdup/kzalloc and others.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/core/rtw_ap.c| 4 ++--
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 2 +-
.../staging/rtl8188eu/include/osdep_service.h | 3 ---
On Sun, Sep 08, 2019 at 01:47:19AM +0300, Vitaly Gaiduk wrote:
> Hi, Andrew.I’m ready to do this property with such name but is it good
> practice to do such long names? :)Also, Trent Piepho wrote about
> sgmii-clk and merged all ideas we have “ti,sgmii-ref-clk”.It’s
> better, isn’t
Hi!
I'm getting this compiling the -next:
CC drivers/net/wireless/intel/iwlwifi/mvm/mac80211.o
In file included from drivers/usb/serial/cp210x.c:23:
./include/linux/gpio/driver.h:722:19: error: static declaration of
‘gpiochip_lock_as_irq’ follows non-static declaration
722 |
On Sun, Sep 08, 2019 at 10:16:02AM +0200, Borislav Petkov wrote:
> On Sun, Sep 08, 2019 at 10:58:31AM +0300, Hawa, Hanna wrote:
> > > Better use WARN_ON_ONCE() to avoid flooding.
> >
> > In case of two drivers using this function with wrong error count, only the
> > first WARN_ON_ONCE will catch
* Qian Cai wrote:
> I thought about making it a bool in the first place, but since all
> other similar helpers (arch_is_kernel_initmem_freed(),
> arch_is_kernel_text(), arch_is_kernel_data() etc) could be bool too but
> are not, I kept arch_is_bss_hole() just to be “int” for consistent.
>
On Sun, Sep 8, 2019 at 10:10 AM Leon Romanovsky wrote:
> On Fri, Sep 06, 2019 at 05:42:37PM +0200, Arnd Bergmann wrote:
>
> I had slightly different fix in my submission queue, which I think is
> better because it leaves length to be size_t.
>
>
syzbot found a crash in dev_map_hash_update_elem(), when replacing an
element with a new one. Jesper correctly identified the cause of the crash
as a race condition between the initial lookup in the map (which is done
before taking the lock), and the removal of the old element.
Rather than just
On Sun, Sep 08, 2019 at 10:58:31AM +0300, Hawa, Hanna wrote:
> > Better use WARN_ON_ONCE() to avoid flooding.
>
> In case of two drivers using this function with wrong error count, only the
> first WARN_ON_ONCE will catch in this case, and other will miss other wrong
> usage of other edac device
On Fri, Sep 06, 2019 at 05:42:37PM +0200, Arnd Bergmann wrote:
> On some 32-bit architectures, size_t is defined as 'int' rather
> than 'long', causing a harmless warning:
>
> drivers/infiniband/core/umem_odp.c:220:7: error: comparison of distinct
> pointer types ('typeof (umem_odp->umem.address)
On Fri, Sep 6, 2019 at 12:08 PM tip-bot2 for Marc Zyngier
wrote:
> The following commit has been merged into the irq/core branch of tip:
>
> Commit-ID: daa19fe5b082779962988a5ba9e38509004db3de
> Gitweb:
> https://git.kernel.org/tip/daa19fe5b082779962988a5ba9e38509004db3de
> Author:
Hillf Danton writes:
>> syzbot has found a reproducer for the following crash on Sat, 07 Sep 2019
>> 18:59:06 -0700
>>
>> HEAD commit:a2c11b03 kcm: use BPF_PROG_RUN
>> git tree: bpf-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=13d46ec160
>> kernel config:
On Wed 2019-08-28 22:32:57, Jacek Anaszewski wrote:
> On 8/28/19 10:53 AM, Pavel Machek wrote:
> > Hi!
> >
> > Eventually, these will be needed.
> >
> > Best regards,
> > Pavel
> >
> > commit 38d956977a7d6cbdc811676f9b4033da7487e045
>
Hi Linus,
some (hopefully last) small GPIO fix for the v5.3 series.
Just affecting PCA953x expanders. Details in the tag.
Please pull it in!
Yours,
Linus Walleij
The following changes since commit a55aa89aab90fae7c815b0551b07be37db359d76:
Linux 5.3-rc6 (2019-08-25 12:01:23 -0700)
are
On 9/5/2019 12:56 PM, Robert Richter wrote:
Hi Hanna,
thanks for the update. See below.
On 05.09.19 09:37:45, Hanna Hawa wrote:
Add an API for edac device to report multiple errors with same type.
Signed-off-by: Hanna Hawa
---
drivers/edac/edac_device.c | 66
On 06/09/2019 17.18, Peter Ujfalusi wrote:
> On systems where multiple DMA controllers available, none Slave (for example
> memcpy operation) users can not be described in DT as there is no device
> involved from the DMA controller's point of view, DMA binding is not usable.
> However in these
On 06/09/2019 17.18, Peter Ujfalusi wrote:
> In case the channel is not requested via the slave API, use the
> of_find_dma_domain() to see if a system default DMA controller is
> specified.
>
> Add new function which can be used by clients to request channels by mask
> from their DMA domain
On Sat, Sep 07, 2019 at 02:26:10PM -0700, Ricardo Neri wrote:
> > Wine users have encountered a number of 64-bit Windows games that use
> > these instructions (particularly sgdt), and were crashing when run on
> > UMIP-enabled systems.
>
> Emulation support for 64-bit processes was not initially
Hello,
syzbot found the following crash on:
HEAD commit:3b47fd5c Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=128438d160
kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4
401 - 500 of 510 matches
Mail list logo
