On 8/12/2020 7:00 PM, Will Deacon wrote:
On Tue, Aug 04, 2020 at 07:44:42PM +0530, Gaurav Kohli wrote:
In a system where no cpu's implement SSBS, for
them no need to set pstate. This might help to save
few cpu cycles during context switch.
Signed-off-by: Gaurav Kohli
diff --git
On Tue, Aug 04, 2020 at 07:44:42PM +0530, Gaurav Kohli wrote:
> In a system where no cpu's implement SSBS, for
> them no need to set pstate. This might help to save
> few cpu cycles during context switch.
>
> Signed-off-by: Gaurav Kohli
>
> diff --git a/arch/arm64/kernel/process.c
Hi,
Please let us know, is below patch good to have
or not for non ssbs systems.
On 8/4/2020 7:44 PM, Gaurav Kohli wrote:
In a system where no cpu's implement SSBS, for
them no need to set pstate. This might help to save
few cpu cycles during context switch.
Signed-off-by: Gaurav Kohli
diff
ult in a
low throughput. It would be hard to mitigate this with filtering in
the congestion control module, because the proper floor to apply would
depend on the method of RTT sampling (using timestamp options or
internally-saved transmission timestamps).
This fix applies a floor of 1 for the RTT sam
ult in a
low throughput. It would be hard to mitigate this with filtering in
the congestion control module, because the proper floor to apply would
depend on the method of RTT sampling (using timestamp options or
internally-saved transmission timestamps).
This fix applies a floor of 1 for the RTT sam
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support three instances;
- the current seq file show
- a show which triggers the bpf_trace/bpf_trace_printk tracepoint
for each portion of the data displayed
Both classes of show function call
From: Yulei Zhang
Construct the direct build ept when guest memory slots have been
changed, and issue mmu_reload request to update the CR3 so that
guest could use the pre-constructed EPT without page fault.
Signed-off-by: Yulei Zhang
---
arch/mips/kvm/mips.c | 13 +
From: Qiuxu Zhuo
Attempt to do function level reset for an RCiEP associated with an
RCEC device on fatal error.
Signed-off-by: Qiuxu Zhuo
---
drivers/pci/pcie/err.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/pcie/err.c
In a system where no cpu's implement SSBS, for
them no need to set pstate. This might help to save
few cpu cycles during context switch.
Signed-off-by: Gaurav Kohli
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6089638..79f80f1 100644
---
On Wed, 29 Jul 2020 13:18:38 +0800, Stanley Chu wrote:
> This patchset introduces and applies DELAY_AFTER_LPM device quirk in MediaTek
> platforms.
>
> Stanley Chu (2):
> scsi: ufs: Introduce device quirk "DELAY_AFTER_LPM"
> scsi: ufs-mediatek: Apply DELAY_AFTER
Looks fine.
Thanks,
Avri
>
> Hi,
> This patchset introduces and applies DELAY_AFTER_LPM device quirk in
> MediaTek platforms.
>
> Stanley Chu (2):
> scsi: ufs: Introduce device quirk "DELAY_AFTER_LPM"
> scsi: ufs-mediatek: Apply DELAY_AFTER_LPM quirk to
Hi,
This patchset introduces and applies DELAY_AFTER_LPM device quirk in MediaTek
platforms.
Stanley Chu (2):
scsi: ufs: Introduce device quirk "DELAY_AFTER_LPM"
scsi: ufs-mediatek: Apply DELAY_AFTER_LPM quirk to Micron devices
drivers/scsi/ufs/ufs-mediatek.c | 2 ++
driver
Micron UFS devices require DELAY_AFTER_LPM device quirk in
MediaTek platforms.
Signed-off-by: Andy Teng
Signed-off-by: Peter Wang
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c
@kernel.org;
Luck,
Tony ;
sathyanarayanan.kuppusw...@linux.intel.com;
linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org; Zhuo, Qiuxu
Subject: Re: [RFC PATCH 5/9] PCI/AER: Apply function level reset to
RCiEP
on fatal error
On Fri, 24 Jul 2020 10:22:19 -0700
Sean V Kelley wrote:
From: Qiuxu Zhuo
shok@kernel.org;
> >> Luck,
> >> Tony ;
> >> sathyanarayanan.kuppusw...@linux.intel.com;
> >> linux-...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; Zhuo, Qiuxu
> >> Subject: Re: [RFC PATCH 5/9] PCI/AER: Apply function level reset to
@vger.kernel.org; Zhuo, Qiuxu
Subject: Re: [RFC PATCH 5/9] PCI/AER: Apply function level reset to
RCiEP
on fatal error
On Fri, 24 Jul 2020 10:22:19 -0700
Sean V Kelley wrote:
From: Qiuxu Zhuo
Attempt to do function level reset for an RCiEP associated with an
RCEC device on fatal error.
I'd
huo, Qiuxu
> Subject: Re: [RFC PATCH 5/9] PCI/AER: Apply function level reset to RCiEP
> on fatal error
>
> On Fri, 24 Jul 2020 10:22:19 -0700
> Sean V Kelley wrote:
>
> > From: Qiuxu Zhuo
> >
> > Attempt to do function level reset for an RCiEP associa
On Fri, 24 Jul 2020 10:22:19 -0700
Sean V Kelley wrote:
> From: Qiuxu Zhuo
>
> Attempt to do function level reset for an RCiEP associated with an
> RCEC device on fatal error.
I'd like to understand more on your reasoning for flr here.
Is it simply that it is all we can do, or is there some
From: Qiuxu Zhuo
Attempt to do function level reset for an RCiEP associated with an
RCEC device on fatal error.
Signed-off-by: Qiuxu Zhuo
---
drivers/pci/pcie/err.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/pcie/err.c
On 2020/7/16 下午1:42, Michael S. Tsirkin wrote:
On Wed, Jul 15, 2020 at 10:02:32PM +0800, Jason Wang wrote:
On 2020/7/15 下午9:58, Michael S. Tsirkin wrote:
VDPA sim stores config space as native endian, but that
is wrong: modern guests expect LE.
I coded up the following to fix it up, but it
On Wed, Jul 15, 2020 at 10:02:32PM +0800, Jason Wang wrote:
>
> On 2020/7/15 下午9:58, Michael S. Tsirkin wrote:
> > VDPA sim stores config space as native endian, but that
> > is wrong: modern guests expect LE.
> > I coded up the following to fix it up, but it is wrong too:
> > vdpasim_create is
On 2020/7/15 下午9:58, Michael S. Tsirkin wrote:
VDPA sim stores config space as native endian, but that
is wrong: modern guests expect LE.
I coded up the following to fix it up, but it is wrong too:
vdpasim_create is called before guest features are known.
So what should we do? New ioctl to
VDPA sim stores config space as native endian, but that
is wrong: modern guests expect LE.
I coded up the following to fix it up, but it is wrong too:
vdpasim_create is called before guest features are known.
So what should we do? New ioctl to specify the interface used?
More ideas?
From: Rajat Jain
[ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ]
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure
From: Rajat Jain
[ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ]
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure
On Fri, Jul 10, 2020 at 02:08:48PM +0200, Oleksij Rempel wrote:
> The ksz8873 and ksz8863 switches are affected by following errata:
This should really be a patch on its own, aimed at net, so it gets
back ported to stable.
Andrew
int ret;
+
+ /* Apply errata workaround for KSZ8863 and KSZ8873:
+* Receiver error in 100BASE-TX mode following Soft Power Down
+*
+* When exiting Soft Power Down mode, the receiver blocks may not start
+* up properly, causing the PHY to miss data and exhib
From: J. Bruce Fields
commit 22cf8419f1319ff87ec759d0ebdff4cbafaee832 upstream.
The server is failing to apply the umask when creating new objects on
filesystems without ACL support.
To reproduce this, you need to use NFSv4.2 and a client and server
recent enough to support umask, and you need
From: J. Bruce Fields
commit 22cf8419f1319ff87ec759d0ebdff4cbafaee832 upstream.
The server is failing to apply the umask when creating new objects on
filesystems without ACL support.
To reproduce this, you need to use NFSv4.2 and a client and server
recent enough to support umask, and you need
From: J. Bruce Fields
commit 22cf8419f1319ff87ec759d0ebdff4cbafaee832 upstream.
The server is failing to apply the umask when creating new objects on
filesystems without ACL support.
To reproduce this, you need to use NFSv4.2 and a client and server
recent enough to support umask, and you need
From: J. Bruce Fields
commit 22cf8419f1319ff87ec759d0ebdff4cbafaee832 upstream.
The server is failing to apply the umask when creating new objects on
filesystems without ACL support.
To reproduce this, you need to use NFSv4.2 and a client and server
recent enough to support umask, and you need
From: Rajat Jain
[ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ]
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure
From: Rajat Jain
[ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ]
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both classes of show function call btf_type_show()
From: Evan Green
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through
From: Evan Green
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through
From: Evan Green
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through
From: Evan Green
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through
From: Evan Green
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through
From: Evan Green
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through
From: Evan Green
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through
From: Evan Green
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through
ons;
}
+/*
+ * Check whether it is time to check and apply the dynamic mmap changes
+ *
+ * Returns true if it is.
+ */
+static bool kdamond_need_update_regions(struct damon_ctx *ctx)
+{
+ return damon_check_reset_time_interval(>last_regions_update,
+ ctx->regions_update
On Wed, Jun 03, 2020 at 06:03:17AM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
>
> Thus we need to ensure tha
On Tue, Jun 2, 2020 at 10:30 PM Mika Westerberg
wrote:
>
> On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > +static bool risky_device(struct pci_dev *pdev)
> > +{
> > + if (pdev->untrusted) {
> > + pci_warn(pdev,
> > + "Skipping IOMMU quirk for
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the device we are applying quirks to, is
indeed an internal trusted device.
Signed-off
On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> +static bool risky_device(struct pci_dev *pdev)
> +{
> + if (pdev->untrusted) {
> + pci_warn(pdev,
> + "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> + " PCI link.
(Trimming text)
On Wed, Jun 03, 2020 at 12:23:48AM +, Rajat Jain wrote:
> On Tue, Jun 2, 2020 at 4:49 PM Prashant Malani wrote:
> >
> > Hi Rajat,
>
> Hi Prashant, thanks for taking a look.
>
> >
> > On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > > +static bool
On Tue, Jun 2, 2020 at 4:49 PM Prashant Malani wrote:
>
> Hi Rajat,
Hi Prashant, thanks for taking a look.
>
> On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > Currently, an external malicious PCI device can masquerade the VID:PID
> > of faulty gfx devic
Hi Rajat,
On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
>
> Thus we
On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
>
> Thus we need to ensure tha
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the device we are applying quirks to, is
indeed an internal trusted device.
Signed-off
nal malicious PCI device can masquerade the VID:PID
> > > of faulty gfx devices, and thus apply iommu quirks to effectively
> > > disable the IOMMU restrictions for itself.
> > >
> > > Thus we need to ensure that the device we are applying quirks to, is
>
Hi Rajat
On Tue, Jun 02, 2020 at 11:41:33AM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
>
> Thus we
Hi MIka,
Thanks for taking a look.
On Tue, Jun 2, 2020 at 2:50 AM Mika Westerberg
wrote:
>
> On Mon, Jun 01, 2020 at 10:45:17PM -0700, Rajat Jain wrote:
> > Currently, an external malicious PCI device can masquerade the VID:PID
> > of faulty gfx devices, and thus
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the device we are applying quirks to, is
indeed an internal trusted device.
Signed-off
void kdamond_split_regions(struct damon_ctx *ctx)
last_nr_regions = nr_regions;
}
+/*
+ * Check whether it is time to check and apply the dynamic mmap changes
+ *
+ * Returns true if it is.
+ */
+static bool kdamond_need_update_regions(struct damon_ctx *ctx)
+{
+ return
On Mon, Jun 01, 2020 at 10:45:17PM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
>
> Thus we need to ensure tha
On 2020/6/2 13:45, Rajat Jain wrote:
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the device we are applying quirks to, is
indeed
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the device we are applying quirks to, is
indeed an internal trusted device.
Signed-off
On 2020-05-25T11:15:03+02:00 SeongJae Park wrote:
> From: SeongJae Park
>
> Only a number of parts in the virtual address space of the processes is
> mapped to physical memory and accessed. Thus, tracking the unmapped
> address regions is just wasteful. However, tracking every memory
>
damon_ctx *ctx)
last_nr_regions = nr_regions;
}
+/*
+ * Check whether it is time to check and apply the dynamic mmap changes
+ *
+ * Returns true if it is.
+ */
+static bool kdamond_need_update_regions(struct damon_ctx *ctx)
+{
+ return damon_check_reset_time_interval
Hello,
On Fri, Apr 10, 2020 at 11:19:55AM +0800, Jitao Shi wrote:
> implement the apply() for pwm.
>
> Fix the clock clk_prepare_enable and clk_disable_unprepare mismatch,
> switch the driver to support the ->apply() method.
Adding support for get_state is a separate chan
On Tue, 2020-05-19 at 17:06 +0100, David Howells wrote:
> Okay, how about this incremental change, then? If fixes the typo, only prints
> the "READ CONFIG" line in verbose mode, filters escape chars in the config
> file and reduces the expiration time to 5s.
>
> David
> ---
> diff --git
3.16.84-rc1 review patch. If anyone has any objections, please let me know.
--
From: Sean Christopherson
commit e30a7d623dccdb3f880fbcad980b0cb589a1da45 upstream.
Remove the bogus 64-bit only condition from the check that disables MMIO
spte optimization when the system
On Tue, May 19, 2020 at 17:06:49 +0100, David Howells wrote:
> Okay, how about this incremental change, then? If fixes the typo, only prints
> the "READ CONFIG" line in verbose mode, filters escape chars in the config
> file and reduces the expiration time to 5s.
Thanks! Looks good to me.
Okay, how about this incremental change, then? If fixes the typo, only prints
the "READ CONFIG" line in verbose mode, filters escape chars in the config
file and reduces the expiration time to 5s.
David
---
diff --git a/key.dns_resolver.c b/key.dns_resolver.c
index c241eda3..7a7ec424 100644
---
* David Howells:
> Fix this to apply a default TTL of 10mins in the event that we haven't got
> one. This can be configured in /etc/keyutils/key.dns_resolver.conf by
> adding the line:
>
> default_ttl:
>
> to the file.
If the name resolution is not needed c
On Tue, May 19, 2020 at 14:39:40 +0100, David Howells wrote:
> Ben Boeckel wrote:
> > Is there precedent for this config file format?
>
> Okay, I can change it to:
>
> default_ttl =
>
> and strip spaces all over the place.
Thanks. This is at least a subset of other formats with specs
about the attached?
David
---
commit cbf0457e0fc99aa5beabe54daeda57be70dfdfce
Author: David Howells
Date: Tue Apr 14 16:07:26 2020 +0100
dns: Apply a default TTL to records obtained from getaddrinfo()
Address records obtained from getaddrinfo() don't come with any TTL
information,
Zero the amount of padding bytes determined in perf_prepare_sample().
This prevents garbage being read from the ring buffer after it has wrapped
the page boundary at least once.
Signed-off-by: Timo Beckers
---
kernel/events/core.c | 12 ++--
1 file changed, 10 insertions(+), 2
On 5/18/20 2:46 AM, Alan Maguire wrote:
On Wed, 13 May 2020, Yonghong Song wrote:
+struct btf_show {
+ u64 flags;
+ void *target; /* target of show operation (seq file, buffer) */
+ void (*showfn)(struct btf_show *show, const char *fmt, ...);
+ const struct btf
On Sun, 17 May 2020 00:09:53 +0800
Changbin Du wrote:
> The tracing option 'irq-info' is only used by function tracer by far. This
> patch makes it also against function graph tracer. Then the two tracers
> have consistent behavior of this option.
>
> Signed-off-by: Changbin Du
> ---
Sorry,
> records unless they include a component obtained directly from the DNS,
> such as an SRV or AFSDB record.
>
> Fix this to apply a default TTL of 10mins in the event that we haven't got
> one. This can be configured in /etc/keyutils/key.dns_resolver.conf by
> adding the l
,
such as an SRV or AFSDB record.
Fix this to apply a default TTL of 10mins in the event that we haven't got
one. This can be configured in /etc/keyutils/key.dns_resolver.conf by
adding the line:
default_ttl:
to the file.
Signed-off-by: David Howells
---
Makefile |1
damon_ctx *ctx)
last_nr_regions = nr_regions;
}
+/*
+ * Check whether it is time to check and apply the dynamic mmap changes
+ *
+ * Returns true if it is.
+ */
+static bool kdamond_need_update_regions(struct damon_ctx *ctx)
+{
+ return damon_check_reset_time_interval
On Wed, 13 May 2020, Yonghong Song wrote:
>
> > +struct btf_show {
> > + u64 flags;
> > + void *target; /* target of show operation (seq file, buffer) */
> > + void (*showfn)(struct btf_show *show, const char *fmt, ...);
> > + const struct btf *btf;
> > + /* below are used during
The tracing option 'irq-info' is only used by function tracer by far. This
patch makes it also against function graph tracer. Then the two tracers
have consistent behavior of this option.
Signed-off-by: Changbin Du
---
kernel/trace/trace_functions_graph.c | 6 +++---
1 file changed, 3
From: Jérôme Pouiller
Strings are allowed to exceed 80 columns but, in this case, the format
arguments should be placed on a new line. Apply this rule to the whole
code of the driver.
Signed-off-by: Jérôme Pouiller
---
drivers/staging/wfx/bus_sdio.c | 3 ++-
drivers/staging/wfx/data_tx.c
On 5/11/20 10:56 PM, Alan Maguire wrote:
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both
generalize the "seq_show" seq file support in btf.c to support
a generic show callback of which we support two instances; the
current seq file show, and a show with snprintf() behaviour which
instead writes the type data to a supplied string.
Both classes of show function call btf_type_show()
damon_ctx *ctx)
last_nr_regions = nr_regions;
}
+/*
+ * Check whether it is time to check and apply the dynamic mmap changes
+ *
+ * Returns true if it is.
+ */
+static bool kdamond_need_update_regions(struct damon_ctx *ctx)
+{
+ return damon_check_reset_time_interval
Good Day
Do you need a Loan?
Thanks
Mr Charles Dickson
Current Intel IOMMU driver sets the system level dma_ops. This causes
each dma API to go through the IOMMU driver even the devices are using
identity mapped domains. This sets per-device dma_ops only if a device
is using a DMA domain. Otherwise, use the default system level dma_ops
for direct dma.
damon_ctx *ctx)
damon_split_regions_of(ctx, t, nr_subregions);
}
+/*
+ * Check whether it is time to check and apply the dynamic mmap changes
+ *
+ * Returns true if it is.
+ */
+static bool kdamond_need_update_regions(struct damon_ctx *ctx)
+{
+ return
etronome.com;
> pa...@netfilter.org; mo...@mellanox.com; m-kariche...@ti.com;
> andre.gue...@linux.intel.com; step...@networkplumber.org
> Subject: Re: [v5,net-next 0/4] Introduce a flow gate control action
> and apply IEEE
>
> From: Po Liu
> Date: Fri, 1 May 2020 08:53:14 +0800
From: Po Liu
Date: Fri, 1 May 2020 08:53:14 +0800
...
> These patches add stream gate action policing in IEEE802.1Qci (Per-Stream
> Filtering and Policing) software support and hardware offload support in
> tc flower, and implement the stream identify, stream filtering and
> stream gate
From: Michael Walle
Date: Wed, 29 Apr 2020 01:06:58 +0200
> The lower three bits of the phy_id specifies the chip stepping. The
> workaround is specifically for the B0 stepping. Apply it only on these
> chips.
>
> Signed-off-by: Michael Walle
> Reviewed-by: Andrew Lunn
>
Changes from V4:
0001:
Fix and modify according to Vlid Buslov suggestions:
- Change spin_lock_bh() to spin_lock() since tcf_gate_act() already in
software irq.
- Remove spin lock protect in the ops->cleanup function.
- Enable the CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING
rnel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.8
Thanks!
[1/1] spi: pxa2xx: Apply CS clk quirk to BXT
commit: 6eefaee4f2d366a389da0eb95e524ba82bf358c4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to L
thus they can create the ordering headaches described
above.
But vmlinux-specific KLP relocations don't have that problem. There's
nothing to prevent them from being applied earlier. So apply them at
the same time as normal relocations, when the KLP module is being
loaded.
This means that for vmlinux-spec
The lower three bits of the phy_id specifies the chip stepping. The
workaround is specifically for the B0 stepping. Apply it only on these
chips.
Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
---
changes since v1:
- added reviewed-by tags
drivers/net
On 4/28/20 2:08 PM, Michael Walle wrote:
> The lower three bits of the phy_id specifies the chip stepping. The
> workaround is specifically for the B0 stepping. Apply it only on these
> chips.
>
> Signed-off-by: Michael Walle
Reviewed-by: Florian Fainelli
--
Florian
On Tue, Apr 28, 2020 at 11:08:53PM +0200, Michael Walle wrote:
> The lower three bits of the phy_id specifies the chip stepping. The
> workaround is specifically for the B0 stepping. Apply it only on these
> chips.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
The lower three bits of the phy_id specifies the chip stepping. The
workaround is specifically for the B0 stepping. Apply it only on these
chips.
Signed-off-by: Michael Walle
---
drivers/net/phy/bcm54140.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers
> @@ -738,18 +765,23 @@ static int klp_init_object_loaded(struct klp_patch
> *patch,
> int ret;
>
> mutex_lock(_mutex);
> -
> module_disable_ro(patch->mod);
> - ret = klp_write_object_relocations(patch->mod, obj);
> - if (ret) {
> -
image. Since we record the PM event in the device
power_state field, we can now recognize the call pattern and apply the
sequence conditionally.
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/pci/hda/patch_realtek.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
image. Since we record the PM event in the device
power_state field, we can now recognize the call pattern and apply the
sequence conditionally.
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/pci/hda/patch_realtek.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
On Fri, Oct 04, 2019 at 02:53:52PM +0200, Fabrice Gasnier wrote:
> Split breakinput routine that configures STM32 timers 'break' safety
> feature upon probe, into two routines:
> - stm32_pwm_apply_breakinputs() sets all the break inputs into registers.
> - stm32_pwm_probe_breakinputs() probes the
--
Hello,
We are private lenders based in UK.
Do you need a loan (credit) as soon as possible. Are you in search of
money to solve your personal needs or finance your business venture,
then get Your desired loan today! Consult us at Sunrise Funding Ltd.
* We offer personal loan & huge capital
401 - 500 of 4625 matches
Mail list logo
