On Mon, Apr 19, 2021 at 7:35 PM Leonardo Bras wrote:
>
> On Mon, 2021-04-19 at 10:44 -0500, Rob Herring wrote:
> > On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras wrote:
> > >
> > > Hello Rob, thanks for this feedback!
> > >
> > > On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote:
> > > > +PPC
Hi Luigi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master]
[cannot apply to next-20210419]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Tue, Mar 30, 2021 at 02:38:10PM CDT, Guenter Roeck wrote:
On Tue, Mar 30, 2021 at 07:02:00PM +0100, Mark Brown wrote:
On Tue, Mar 30, 2021 at 12:56:56PM -0500, Zev Weiss wrote:
> Okay, to expand a bit on the description in my initial message -- we've
> got a single chassis with multiple
On Mon, Apr 19, 2021 at 3:11 PM Steven Rostedt wrote:
>
> On Mon, 19 Apr 2021 21:54:13 +
> "Williams, Dan J" wrote:
>
> > [ drop Rusty, add Jessica and Emmanuel ]
>
> Probably could have kept Jessica on as she's the module maintainer.
Oh, you misread, I swapped out Rusty for Jessica on the
Hi Baolu,
On 2021/4/19 21:33, Lu Baolu wrote:
> Hi Keqian,
>
> On 2021/4/19 17:32, Keqian Zhu wrote:
+EXPORT_SYMBOL_GPL(iommu_split_block);
>>> Do you really have any consumers of this interface other than the dirty
>>> bit tracking? If not, I don't suggest to make this as a generic IOMMU
On Mon, Apr 19, 2021 at 7:46 PM Arnd Bergmann wrote:
>
> On Sat, Apr 17, 2021 at 6:45 AM wrote:
> > +#define arch_atomic_read(v)__READ_ONCE((v)->counter)
> > +#define arch_atomic_set(v, i)
> > __WRITE_ONCE(((v)->counter), (i))
>
> > +#define ATOMIC64_INIT
On Mon, Apr 19, 2021 at 08:46:59AM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
>
> For example, some devices, such as
On Mon, Apr 19, 2021 at 2:01 AM Peter Zijlstra wrote:
>
> Josh, you being on the other Google team, the one that actually uses the
> cgroup interface AFAIU, can you fight the good fight with TJ on this?
A bit of extra context is in
On Tue, Apr 20, 2021, Paolo Bonzini wrote:
> On 19/04/21 17:09, Sean Christopherson wrote:
> > > - this loses the rwsem fairness. On the other hand, mm/mmu_notifier.c's
> > > own interval-tree-based filter is also using a similar mechanism that is
> > > likewise not fair, so it should be okay.
>
On 21-04-19 09:53:11, Pawel Laszczak wrote:
> From: Pawel Laszczak
>
> Patch fixes lack of removing request from ep->pending_list on failure
> of the stop endpoint command. Driver even after failing this command
> must remove request from ep->pending_list.
> Without this fix driver can stuck in
On Tue, Apr 20, 2021 at 3:22 AM Jonathan Corbet wrote:
>
> Fox Chen writes:
>
> > On Mon, Apr 19, 2021 at 11:25 AM Matthew Wilcox wrote:
> >>
> >> On Mon, Apr 19, 2021 at 10:33:00AM +0800, Fox Chen wrote:
> >> > On Mon, Apr 19, 2021 at 10:17 AM Matthew Wilcox
> >> > wrote:
> >> > > You can
On Wed, Apr 14, 2021 at 4:20 AM Tiezhu Yang wrote:
>
> There exist some errors "404 Not Found" when I click the link
> of "MAINTAINERS" [1], "samples/bpf/" [2] and "selftests" [3]
> in the documentation "HOWTO interact with BPF subsystem" [4].
>
> Use correct link of "MAINTAINERS" and just remove
> On 4/18/21 10:49 PM, Changheun Lee wrote:
> >>> @@ -167,6 +168,7 @@ void blk_queue_max_hw_sectors(struct request_queue
> >>> *q, unsigned int max_hw_secto
> >>> max_sectors = round_down(max_sectors,
> >>>limits->logical_block_size >> SECTOR_SHIFT);
> >>>
在 2021/4/19 18:56, Youling Tang 写道:
From: Huacai Chen
kexec-tools use mem=X@Y to pass usable memories to crash kernel, but in
commit a94e4f24ec836c8984f83959 ("MIPS: init: Drop boot_mem_map") all
BIOS passed memories are removed by early_parse_mem(). I think this is
reasonable for a normal
On 21-04-19 09:50:53, Pawel Laszczak wrote:
> From: Pawel Laszczak
>
> Patch adds disabling endpoint before enabling it during changing
> alternate setting. Lack of this functionality causes that in some
> cases uac2 queue the same request multiple time.
> Such situation can occur when host send
在 2021/4/19 18:50, Youling Tang 写道:
This problem may only occur on NUMA platforms. When machine start with the
"mem=" parameter on Loongson64, it cannot boot. When parsing the "mem="
parameter, first remove all RAM, and then add memory through memblock_add(),
which causes the newly added
On 21-04-19 12:57:20, Wesley Cheng wrote:
> From: Hemant Kumar
>
> Upon driver unbind usb_free_all_descriptors() function frees all
> speed descriptor pointers without setting them to NULL. In case
> gadget speed changes (i.e from super speed plus to super speed)
> after driver unbind only upto
On Mon, Apr 19, 2021 at 06:28:21PM -0600, Jane Chu wrote:
> It appears that unmap_mapping_range() actually takes a 'size' as its
> third argument rather than a location, the current calling fashion
> causes unecessary amount of unmapping to occur.
>
> Fixes: 6100e34b2526e ("mm, memory_failure:
On 4/19/21 4:56 PM, Samuel Mendoza-Jonas wrote:
The 4.14 backport of 9d7eceede ("bpf: restrict unknown scalars of mixed
signed bounds for unprivileged") adds the PTR_TO_MAP_VALUE check to the
wrong location in adjust_ptr_min_max_vals(), most likely because 4.14
doesn't include the commit that
On Mon, 2021-04-19 at 10:44 -0500, Rob Herring wrote:
> On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras wrote:
> >
> > Hello Rob, thanks for this feedback!
> >
> > On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote:
> > > +PPC and PCI lists
> > >
> > > On Thu, Apr 15, 2021 at 1:01 PM Leonardo
On Mon, Apr 19, 2021 at 5:28 PM Jane Chu wrote:
>
> It appears that unmap_mapping_range() actually takes a 'size' as its
> third argument rather than a location,
Indeed.
> the current calling fashion
> causes unecessary amount of unmapping to occur.
s/unecessary/unnecessary/
>
> Fixes:
The current flag name "untrusted" is not correct as it is populated
using the firmware property "external-facing" for the parent ports. In
other words, the firmware only says which ports are external facing, so
the field really identifies the devices as external (vs internal).
Only field
It appears that unmap_mapping_range() actually takes a 'size' as its
third argument rather than a location, the current calling fashion
causes unecessary amount of unmapping to occur.
Fixes: 6100e34b2526e ("mm, memory_failure: Teach memory_failure() about
dev_pagemap pages")
Signed-off-by: Jane
On kunpeng920, cpus within one cluster can communicate wit each other
much faster than cpus across different clusters. A simple hackbench
can prove that.
hackbench running on 4 cpus in single one cluster and 4 cpus in
different clusters shows a large contrast:
(1) within a cluster:
root@ubuntu:~#
From: Tim Chen
There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce
is shared among a cluster of cores instead of being exclusive
to one single core.
To prevent oversubscription of L2 cache, load should be
balanced between such L2 clusters, especially for tasks with
no shared data.
ARM64 chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data, but each cluster
has local L3 tag. On the other hand, each clusters will share some
internal system bus. This means cache coherence overhead inside one
cluster is much less
From: Jonathan Cameron
Both ACPI and DT provide the ability to describe additional layers of
topology between that of individual cores and higher level constructs
such as the level at which the last level cache is shared.
In ACPI this can be represented in PPTT as a Processor Hierarchy
Node
ARM64 server chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data while each cluster has
local L3 tag. On the other hand, each cluster will share some internal system
bus. This means cache is much more affine inside one cluster than
On Fri, Apr 16, 2021 at 10:39 AM Willy Tarreau wrote:
>
> resources usage, I'm really not convinced at all it's suited for
> low-level development. I understand the interest of the experiment
> to help the language evolve into that direction, but I fear that
> the kernel will soon be as bloated
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a003-20210419
x86_64 randconfig-a001-20210419
x86_64 randconfig-a005-20210419
x86_64 randconfig-a002
On Mon, Apr 19, 2021 at 03:04:40PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.11.16 release.
> There are 122 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Apr 19, 2021 at 03:05:51PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.114 release.
> There are 73 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Fix an 11-year old bug in ngene_command_config_free_buf() while
addressing the following warnings caught with -Warray-bounds:
arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12,
16] from the object at 'com' is out of the bounds of referenced subobject
'config' with
On Fri, Apr 16, 2021 at 03:31:53PM +0530, Sandeep Maheswaram wrote:
> Subject: usb: dwc3: qcom: Set genpd active wakeup flag for usb gdsc
>
> Set genpd active wakeup flag for usb gdsc if wakeup capable devices
> are connected so that wake up happens without reenumeration.
Better describe things
On 4/19/21 7:05 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.4.114 release.
There are 73 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 4/19/21 7:05 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.32 release.
There are 103 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 4/19/21 7:04 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.11.16 release.
There are 122 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On Tue, Apr 20, 2021 at 12:06:24AM +0800, John Garry wrote:
> Function sdev_store_queue_depth() enforces that the sdev queue depth cannot
> exceed shost.can_queue.
>
> However, the LLDD may still set cmd_per_lun > can_queue, which leads to an
> initial sdev queue depth greater than can_queue.
>
The 'all' semantics is now supported by the bitmap_parselist() so we can
drop supporting it as a special case in RCU code. This patch does not
add any functional changes for existing users.
Signed-off-by: Yury Norov
---
kernel/rcu/tree_plugin.h | 9 +++--
1 file changed, 3 insertions(+), 6
RCU code supports a special group 'all' which selects all bits in a bitmap.
We have recently added 'N' extension for bitmap parse, so that '0-N' would
have exactly the same meaning as 'all'. But because the 'all' is already
used by RCU, it would be reasonable to support it in core bitmap code as a
RCU code supports an 'all' group as a special case when parsing
rcu_nocbs parameter. This patch moves the 'all' support to the core
bitmap_parse code, so that all bitmap users can enjoy this extension.
Moving 'all' parsing to a bitmap_parse level, also allows users to
pass patterns together with
On 4/19/21 2:33 PM, Len Brown via Libc-alpha wrote:
the AI guys are super excited about matrix multiplication,
but I have a hard time imagining why grep(1) would find a use for it.
I don't. Matrix multiplication is used in modern string-searching
algorithms that could be useful in running
The 4.14 backport of 9d7eceede ("bpf: restrict unknown scalars of mixed
signed bounds for unprivileged") adds the PTR_TO_MAP_VALUE check to the
wrong location in adjust_ptr_min_max_vals(), most likely because 4.14
doesn't include the commit that updates the if-statement to a
switch-statement
On Mon, Apr 19, 2021 at 05:29:46PM +0200, Michal Kubecek wrote:
>
> As pointed out in the discussion on v3, this patch may result in
> significantly higher CPU consumption with multiple threads competing on
> a saturated outgoing device. I missed this submission so that I haven't
> checked it yet
0x2B, 0x31 and 0x33 are reserved for future use but were not present in
the HCI to MGMT conversion table, this caused the conversion to be
incorrect for the HCI status code greater than 0x2A.
Reviewed-by: Miao-chen Chou
Signed-off-by: Yu Liu
---
Changes in v1:
- Initial change
On Mon, 2021-04-19 at 14:58 -0500, Terry Bowman wrote:
@@ -3281,7 +3326,7 @@ static int update_msr_sum(struct thread_data *t, struct
core_data *c, struct pkg
continue;
ret = get_msr(cpu, offset, _cur);
if (ret) {
-
Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> In some cases, you can use the device_link infrastructure to deal
> with dependencies between devices. Not sure if this would help
> in your case, but have a look at device_link_add() etc in drivers/base/core.c
I'll need to actually
On 4/15/21 1:40 AM, Muchun Song wrote:
> Add a kernel parameter hugetlb_free_vmemmap to enable the feature of
> freeing unused vmemmap pages associated with each hugetlb page on boot.
>
> We disables PMD mapping of vmemmap pages for x86-64 arch when this
> feature is enabled. Because
On 4/19/21 12:38 PM, Johannes Weiner wrote:
On Sun, Apr 18, 2021 at 08:00:29PM -0400, Waiman Long wrote:
Before the new slab memory controller with per object byte charging,
charging and vmstat data update happen only when new slab pages are
allocated or freed. Now they are done with every
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: bf05bf16c76bb44ab5156223e1e58e26dfe30a88
commit: bbd7ffdbef6888459f301c5889f3b14ada38b913 clk: Allow the common clk
framework to be selectable
date: 12 months ago
config: s390-randconfig-r036-20210419
Hi,
On Mon, Apr 19, 2021 at 11:26:08AM +0200, Lukas Bulwahn wrote:
> Commit 7a6ff4c4cbc3 ("misc: hisi_hikey_usb: Driver to support onboard USB
> gpio hub on Hikey960") refers to the non-existing file
> ./Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml, but this
> commit's patch
I changed the comment to
+ /*
+* See commit 2f94a3125b87. Increment the refcount when we
+* get a lease for root, release it if lease break occurs
+*/
and added Aurelien's Reviewed-by. Let me know if you see any
additional problems.
On Tue, Apr 13, 2021 at 08:54:06AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 12, 2021 at 01:05:09PM -0700, Kees Cook wrote:
> > On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > > +struct vpr_data {
> > > + int (*fn)(pte_t pte, unsigned long addr, void *data);
> > > + void
> From: Chris von Recklinghausen
> Sent: Friday, April 16, 2021 6:17 AM
> ...
> Hibernation fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> The check is intended to detect whether the E820 memory map provided
> by
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Mon, 19 Apr 2021 19:13:58 +0300 you wrote:
> Hi,
>
> This small series adds the TJA1103 PHY driver.
>
> Changes in v3:
> - use phy_read_mmd_poll_timeout instead of spin_until_cond
> - changed the phy name from a
Hi,
Thanks for your patch.
On Mon, Apr 19, 2021 at 11:26:07AM +0200, Lukas Bulwahn wrote:
> Commit 836863a08c99 ("MAINTAINERS: Add information for Toshiba Visconti ARM
> SoCs") refers to the non-existing file toshiba,tmpv7700-pinctrl.yaml in
> ./Documentation/devicetree/bindings/pinctrl/. Commit
On Mon 19 Apr 15:59 CDT 2021, AngeloGioacchino Del Regno wrote:
> Il 19/04/21 20:52, Bjorn Andersson ha scritto:
> > On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:
[..]
> > > +static int qcom_cpufreq_hw_acd_init(struct device *cpu_dev,
> > > + struct
On Fri, Apr 16, 2021 at 03:31:52PM +0530, Sandeep Maheswaram wrote:
> Configure interrupts based on hs_phy_mode to avoid triggering of
> interrupts during system suspend and suspend the device successfully.
>
> Signed-off-by: Sandeep Maheswaram
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 26
Hi Rob,
Thanks for the inputs.
On Fri, Apr 9, 2021 at 11:34 AM Rob Herring wrote:
>
> On Wed, Apr 07, 2021 at 11:50:38AM -0700, Manish Varma wrote:
> > I2C devices currently are named dynamically using
> > - convention, unless they are instantiated
> > through ACPI.
> >
> > This means the
On 4/15/21 1:40 AM, Muchun Song wrote:
> When we free a HugeTLB page to the buddy allocator, we need to allocate
> the vmemmap pages associated with it. However, we may not be able to
> allocate the vmemmap pages when the system is under memory pressure. In
> this case, we just refuse to free the
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sat, 17 Apr 2021 02:17:51 +0300 you wrote:
> From: Vadym Kochan
>
> Add PCI match for AC3X 98DX3265 device which is supported by the current
> driver and firmware.
>
> Signed-off-by: Vadym Kochan
>
> [...]
Here is
From: Nick Desaulniers
"o" isn't a common asm() constraint to use; it triggers an assertion in
assert-enabled builds of LLVM that it's not recognized when targeting
aarch64 (though it appears to fall back to "m"). I've fixed this in LLVM
13 now, but there isn't really a good reason to be using
On Fri, Apr 16, 2021 at 03:31:50PM +0530, Sandeep Maheswaram wrote:
> Avoiding phy powerdown when wakeup capable devices are connected
> by checking phy_power_off flag.
> Phy should be on to wake up the device from suspend using wakeup capable
> devices such as keyboard and mouse.
>
>
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Mon, 19 Apr 2021 00:19:38 +0200 you wrote:
> While converting Mikrotik RB532 support to use device tree I stumbled
> over the korina ethernet driver, which used way too many MIPS specific
> hacks. This series cleans
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Mon, 19 Apr 2021 19:25:30 +0800 you wrote:
> On driver probe, kmemleak reported the following memory leak which was
> due to allocated bitmap that was not being freed in stmmac_dvr_probe().
>
> unreferenced object
On Thu, Apr 15, 2021, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Add new KVM_FEATURE_SEV_LIVE_MIGRATION feature for guest to check
> for host-side support for SEV live migration. Also add a new custom
> MSR_KVM_SEV_LIVE_MIGRATION for guest to enable the SEV live migration
> feature.
>
> MSR
From: "H. Peter Anvin (Intel)"
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target, which can be booted
From: "H. Peter Anvin (Intel)"
Make it easy to generate a disk image which includes the all-modules
initramfs image.
Signed-off-by: H. Peter Anvin (Intel)
---
arch/x86/Makefile | 3 ++-
arch/x86/boot/Makefile | 20
2 files changed, 18 insertions(+), 5 deletions(-)
From: "H. Peter Anvin (Intel)"
Some distributions really cannot be booted without modules
anymore. To allow an externally built kernel to be run, it is handy to
be able to create an initramfs image with all the modules, that can
appended to an existing initramfs image (preferrably without any
From: "H. Peter Anvin" (Intel)
When compiling on a different machine than the runtime target,
including but not limited to simulators, it is rather handy to be able
to produce a bootable image. The scripts for that in x86 are
relatively old, and assume a BIOS system.
This adds a build target to
On 4/17/21 12:52, Kalle Valo wrote:
> "Gustavo A. R. Silva" wrote:
>
>> In preparation to enable -Wimplicit-fallthrough for Clang, fix
>> multiple warnings by replacing /* fall through */ comments with
>> the new pseudo-keyword macro fallthrough; instead of letting the
>> code fall through to
On Mon, Apr 19, 2021 at 08:09:13PM +, Sean Christopherson wrote:
> On Mon, Apr 19, 2021, Kirill A. Shutemov wrote:
> > On Mon, Apr 19, 2021 at 06:09:29PM +, Sean Christopherson wrote:
> > > On Mon, Apr 19, 2021, Kirill A. Shutemov wrote:
> > > > On Mon, Apr 19, 2021 at 04:01:46PM +,
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
v2:
* Fix line-wrapping in
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over
While this shouldn't really be something that happens all that often, since
we're going to be using the drm_dbg_* log helpers in DRM helpers it's
technically possible that a driver could use an AUX adapter before it's
been associated with it's respective drm_device. While drivers should take
care
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(dev, expr);
|
- DRM_ERROR(expr);
+
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c |
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed,
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
On Mon, Apr 19, 2021 at 10:50:43PM +, Dennis Zhou wrote:
> Hello,
>
> This series is a continuation of Roman's series in [1]. It aims to solve
> chunks holding onto free pages by adding a reclaim process to the percpu
> balance work item.
>
> The main difference is that the
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
1 file changed, 20 insertions(+), 5
When moving around drm_dp_aux_register() calls, it turned out we
accidentally managed to cause issues with the Tegra driver due to the fact
the Tegra driver would attempt to retrieve a reference to the AUX channel's
i2c adapter - which wouldn't be initialized until drm_dp_aux_register() is
called.
+Bob and Rafael
> -Original Message-
> From: Dan Williams
> Sent: Friday, April 16, 2021 3:09 PM
> To: Andy Shevchenko
> Cc: linux-nvdimm ; Linux Kernel Mailing List
> ; Verma, Vishal L
> ; Jiang, Dave ; Weiny, Ira
> ; Kaneda, Erik
> Subject: Re: [PATCH v1 1/1] libnvdimm: Don't use
While working on moving i2c device registration into drm_dp_aux_init() - I
realized that in order to do so we need to make sure that drivers calling
drm_dp_aux_init() handle any errors it could possibly return. In the
process of doing that, I noticed that the majority of AMD's code for DP
Since we're about to make it so that drm_dp_aux_init() can fail (and thus -
should have it's return value checked) - we should require that callers of
drm_dp_aux_register() also check it's return value since drm_dp_aux_init()
can be called from there.
Signed-off-by: Lyude Paul
---
On Mon, Apr 19, 2021 at 10:50:43PM +, Dennis Zhou wrote:
> Hello,
>
> This series is a continuation of Roman's series in [1]. It aims to solve
> chunks holding onto free pages by adding a reclaim process to the percpu
> balance work item.
>
And I forgot to link [1]...
[1]
On Mon, Apr 19, 2021 at 05:52:39PM +0200, Florent Revest wrote:
> This type provides the guarantee that an argument is going to be a const
> pointer to somewhere in a read-only map value. It also checks that this
> pointer is followed by a zero character before the end of the map value.
>
>
From: Roman Gushchin
This patch implements partial depopulation of percpu chunks.
As of now, a chunk can be depopulated only as a part of the final
destruction, if there are no more outstanding allocations. However
to minimize a memory waste it might be useful to depopulate a
partially filed
The last patch implements reclaim by adding 2 additional lists where a
chunk's lifecycle is:
active_slot -> to_depopulate_slot -> sidelined_slot
This worked great because we're able to nicely converge paths into
isolation. However, it's a bit aggressive to run for every free page.
Let's
This prepares for adding a to_depopulate list and sidelined list after
the free slot in the set of lists in pcpu_slot.
Signed-off-by: Dennis Zhou
---
mm/percpu.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index
From: Roman Gushchin
Factor out the pcpu_check_block_hint() helper, which will be useful
in the future. The new function checks if the allocation can likely
fit within the contig hint.
Signed-off-by: Roman Gushchin
Signed-off-by: Dennis Zhou
---
mm/percpu.c | 30
101 - 200 of 1444 matches
Mail list logo
