search for: list_for_each_entri

On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul <lyude at redhat.com> wrote: > > Currently, every single piece of code in amdgpu that loops through > connectors does it incorrectly and doesn't use the proper list iteration > helpers, drm_connector_list_iter_begin() and > drm_connector_list_iter_end(). Yeesh. > > So, do that. In fairness, I think the origin of this code

Currently, every single piece of code in amdgpu that loops through connectors does it incorrectly and doesn't use the proper list iteration helpers, drm_connector_list_iter_begin() and drm_connector_list_iter_end(). Yeesh. So, do that. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry

Signed-off-by: Christoph Hellwig <hch@lst.de> Index: linux-2.6/fs/ocfs2/cluster/tcp.c =================================================================== --- linux-2.6.orig/fs/ocfs2/cluster/tcp.c 2007-05-06 13:51:17.000000000 +0200 +++ linux-2.6/fs/ocfs2/cluster/tcp.c 2007-05-17 15:00:14.000000000 +0200 @@ -261,14 +261,12 @@ out: static void o2net_complete_nodes_nsw(struct o2net_node

Use struct msi_ops to hook PCI MSI operations, and use struct msi_irqs to refactor PCI MSI drvier. Signed-off-by: Yijing Wang <wangyijing at huawei.com> --- drivers/pci/msi.c | 351 ++++++++++++++++++++++++++++++--------------------- include/linux/msi.h | 14 +- include/linux/pci.h | 11 +- 3 files changed, 222 insertions(+), 154 deletions(-) diff --git a/drivers/pci/msi.c

merge list_for_each and list_entry to list_for_each_entry. Signed-off-by: Qinghuang Feng <qhfeng.kernel@gmail.com> --- diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index b187b53..70f0248 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -104,10 +104,8 @@ static noinline struct btrfs_device *__find_device(struct list_head *head, u64 devid, u8 *uuid) { struct

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

''bh'' is forgot to release if no error is detected Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> --- fs/btrfs/volumes.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 8b9fb8c..69fc902 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -631,6 +631,7 @@ static int

The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any

This patch set includes two instances where the list iterator variable 'pstate' is implicitly assumed to be valid after the iterator loop. While in pratice that is most likely the case (if 'pstatei'/'args->v0.state' is <= the elements in clk->states), we should explicitly only allow 'pstate' to always point to correct 'nvkm_pstate' structs. That

This reorders the list to keep track of what buffers are reserved, so previous members are always unreserved. This gets rid of some bookkeeping that's no longer needed, while simplifying the code some. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/qxl/qxl_release.c | 1 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 142

Hi Ben, still _assuming_ it's an issue of the card I thought about why it works with the NVIDIA binary driver. And I can image they're just trying to do an identity-mapping first and if that doesn't work (e.g. the particular SOR is already in use by another macro link) they just pick the next suitable one. So the case would be that the NVIDIA binary driver always assignes the only

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

On 2017-09-15 — 17:11, Karol Herbst wrote: > This makes the code easier, because we can compare the id with > pstate->pstate and saves us from the trouble of iterating over the pstates > to match the index. I don’t remember whether I have already done this comment before, but I am not sure where your iterating over the pstates savings are, as in this patch at least, you iterate as

MSI interrupt will not only used in PCI device, more and more Non-PCI device also want to use MSI. ARM GIC v3 spec says in ARM platform with GIC v3 controller, Non-PCI device can also be design to support MSI to simplify interrupt wires, for the existing Non-PCI device, consolidator is designed and used to translate legacy interrupt to MSI. So for support Non-PCI MSI device, generic MSI driver is

Hi Amit, Rusty RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062 steps: - Read random data by 'dd if=/dev/hwrng of=/dev/null' in guest - check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*' Result: cat process will get stuck, it will return if we kill dd process. We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c,

Hi Amit, Rusty RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062 steps: - Read random data by 'dd if=/dev/hwrng of=/dev/null' in guest - check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*' Result: cat process will get stuck, it will return if we kill dd process. We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c,

Seems to make suspend slightly more reliable on my system. Cc: stable at vger.kernel.org [3.7+] Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index b6bdc9f..5032c31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -464,6

On Thu, Sep 26, 2019 at 12:33:36PM -0700, Eric Dumazet wrote: > > > On 9/26/19 11:23 AM, Matias Ezequiel Vara Larsen wrote: > > This patch adds support for MSG_PEEK. In such a case, packets are not > > removed from the rx_queue and credit updates are not sent. > > > > Signed-off-by: Matias Ezequiel Vara Larsen <matiasevara at gmail.com> > > --- >