On 2/19/24 5:47 AM, Ricardo B. Marliere wrote:
> Since commit aed65af1cc2f ("drivers: make device_type const"), the driver
> core can properly handle constant struct device_type. Move the
> dax_mapping_type variable to be a constant structure as well, placing it
> into read-only memory which
On Fri, 23 Feb 2024 22:28:42 +0100, Pavel Machek wrote:
> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> but I did best I could.
>
> Signed-off-by: Pavel Machek
>
> ---
>
> v2: implement review feedback
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m
From: Ondrej Jirman
This is driver for ANX7688 USB-C HDMI, with flashing and debugging
features removed. ANX7688 is rather criticial piece on PinePhone,
there's no display and no battery charging without it.
There's likely more work to be done here, but having basic support
in mainline is
Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
but I did best I could.
Signed-off-by: Pavel Machek
---
v2: implement review feedback
diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
From: "Steven Rostedt (Google)"
The second parameter of __assign_rel_str() is no longer used. It can be removed.
Note, the only real users of rel_string is user events. This code is just
in the sample code for testing purposes.
This makes __assign_rel_str() different than __assign_str() but
From: "Steven Rostedt (Google)"
In preparation to remove the second parameter of __assign_str(), make sure
it is really a duplicate of __string() by adding a WARN_ON_ONCE().
Signed-off-by: Steven Rostedt (Google)
---
Changes since v1:
From: "Steven Rostedt (Google)"
In preparation to remove the second parameter of __assign_str(), make sure
it is really a duplicate of __string() by adding a WARN_ON_ONCE().
Signed-off-by: Steven Rostedt (Google)
---
include/trace/stages/stage6_event_callback.h | 1 +
1 file changed, 1
On Fri, 23 Feb 2024 13:46:53 -0500
Steven Rostedt wrote:
> Now one thing I could do is to not remove the parameter, but just add:
>
> WARN_ON_ONCE((src) != __data_offsets->item##_ptr_);
>
> in the __assign_str() macro to make sure that it's still the same that is
> assigned. But I'm not
From: "Steven Rostedt (Google)"
There's no example code that uses __string_len(), and since the sample
code is used for testing the event logic, add a use case.
Signed-off-by: Steven Rostedt (Google)
---
samples/trace_events/trace-events-sample.h | 7 +--
1 file changed, 5 insertions(+),
From: "Steven Rostedt (Google)"
Now that __assign_str() gets the length from the __string() (and
__string_len()) macros, there's no reason to have a separate
__assign_str_len() macro as __assign_str() can get the length of the
string needed.
Also remove __assign_rel_str() although it had no
On Fri, 23 Feb 2024 14:50:49 -0500
Kent Overstreet wrote:
> Tangentially related though, what would make me really happy is if we
> could create the string with in the TP__fast_assign() section. I have to
> have a bunch of annoying wrappers right now because the string length
> has to be known
On Fri, Feb 23, 2024 at 01:46:53PM -0500, Steven Rostedt wrote:
> On Fri, 23 Feb 2024 10:30:45 -0800
> Jeff Johnson wrote:
>
> > On 2/23/2024 9:56 AM, Steven Rostedt wrote:
> > > From: "Steven Rostedt (Google)"
> > >
> > > [
> > >This is a treewide change. I will likely re-create this
From: "Steven Rostedt (Google)"
Now that __assign_str() gets the length from the __string() (and
__string_len()) macros, there's no reason to have a separate
__assign_str_len() macro as __assign_str() can get the length of the
string needed.
Signed-off-by: Steven Rostedt (Google)
---
On Thu, 22 Feb 2024 16:44:45 -0600, Huang, Kai wrote:
On 23/02/2024 5:36 am, Haitao Huang wrote:
On Wed, 21 Feb 2024 05:23:00 -0600, Huang, Kai
wrote:
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
From: Kristen Carlson Accardi
Previous patches have implemented all
On Fri, 23 Feb 2024 10:30:45 -0800
Jeff Johnson wrote:
> On 2/23/2024 9:56 AM, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > [
> >This is a treewide change. I will likely re-create this patch again in
> >the second week of the merge window of v6.9 and submit it
On Fri, Feb 23, 2024 at 02:54:13PM +0100, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 2/22/24 20:02, Mathieu Poirier wrote:
> > Hi,
> >
> > On Wed, Feb 14, 2024 at 06:21:27PM +0100, Arnaud Pouliquen wrote:
> >> The new TEE remoteproc device is used to manage remote firmware in a
> >> secure,
On 2/23/2024 9:56 AM, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.9 and submit it then. Hoping
>to keep the conflicts that it will cause to a minimum.
On Wed, Feb 14, 2024 at 06:21:23PM +0100, Arnaud Pouliquen wrote:
> Add a check on the optional rproc->cached_table to perform the memory
> copy only if it is not null.
>
> 2 use cases to support:
> - starting on boot, in which case rproc->cached_table can be null,
> - starting on crash recovery,
On Wed, Feb 14, 2024 at 06:21:21PM +0100, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this device offers a client
>
On Fri, 23 Feb 2024 12:56:34 -0500
Steven Rostedt wrote:
> Note, the same updates will need to be done for:
>
> __assign_str_len()
> __assign_rel_str()
> __assign_rel_str_len()
Correction: The below macros do not pass in their source to the entry
macros, so they will not need to be
On Thu, Feb 22, 2024 at 9:59 AM Carlos Galo wrote:
>
> On Thu, Feb 22, 2024 at 6:16 AM Michal Hocko wrote:
> >
> > On Wed 21-02-24 13:30:51, Carlos Galo wrote:
> > > On Tue, Feb 20, 2024 at 11:55 PM Michal Hocko wrote:
> > > >
> > > > Hi,
> > > > sorry I have missed this before.
> > > >
> > > >
The current implementation of the mark_victim tracepoint provides only
the process ID (pid) of the victim process. This limitation poses
challenges for userspace tools requiring real-time OOM analysis and
intervention. Although this information is available from the kernel
logs, it’s not the
On Fri, 23 Feb 2024 04:18:18 -0600, Huang, Kai wrote:
>
Right. When code reaches to here, we already passed reclaim per cgroup.
Yes if try_charge() failed we must do pre-cgroup reclaim.
The cgroup may not at or reach limit but system has run out of physical
EPC.
But after try_charge()
On 2/22/24 10:55, Naman Jain wrote:
> On 2/22/2024 2:17 PM, Arnaud POULIQUEN wrote:
>> Hello Naman,
>>
>> On 2/22/24 06:43, Naman Jain wrote:
>>> On 2/14/2024 10:51 PM, Arnaud Pouliquen wrote:
Updates from the previous version [1]:
This version proposes another approach based on
Hello Mathieu,
On 2/22/24 20:02, Mathieu Poirier wrote:
> Hi,
>
> On Wed, Feb 14, 2024 at 06:21:27PM +0100, Arnaud Pouliquen wrote:
>> The new TEE remoteproc device is used to manage remote firmware in a
>> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
>> introduced to
On Fri, Feb 23, 2024 at 12:58 PM Breno Leitao wrote:
>
> With commit 34d21de99cea9 ("net: Move {l,t,d}stats allocation to core and
> convert veth & vrf"), stats allocation could be done on net core
> instead of this driver.
>
> With this new approach, the driver doesn't have to bother with error
On Fri, Feb 23, 2024 at 12:58 PM Breno Leitao wrote:
>
> Do not set rtnl_link_stats64 fields to zero, since they are zeroed
> before ops->ndo_get_stats64 is called in core dev_get_stats() function.
>
> Signed-off-by: Breno Leitao
Reviewed-by: Eric Dumazet
Do not set rtnl_link_stats64 fields to zero, since they are zeroed
before ops->ndo_get_stats64 is called in core dev_get_stats() function.
Signed-off-by: Breno Leitao
---
drivers/net/vsockmon.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/vsockmon.c b/drivers/net/vsockmon.c
With commit 34d21de99cea9 ("net: Move {l,t,d}stats allocation to core and
convert veth & vrf"), stats allocation could be done on net core
instead of this driver.
With this new approach, the driver doesn't have to bother with error
handling (allocation failure checking, making sure free happens
On Wed, Jan 31, 2024 at 2:28 PM Yan Zhao wrote:
>
> Apply the page shift to PFN to get physical address for final VA.
> The macro __va should take physical address instead of PFN as input.
>
> Fixes: c1884e1e1164 ("csky: Make pfn accessors static inlines")
> Signed-off-by: Yan Zhao
> ---
>
On Wed, Jan 31, 2024 at 2:27 PM Yan Zhao wrote:
>
> Apply the page shift to PFN to get physical address for final VA.
> The macro __va should take physical address instead of PFN as input.
>
> Fixes: 2d78057f0dd4 ("asm-generic/page.h: Make pfn accessors static inlines")
> Signed-off-by: Yan Zhao
> >
> Right. When code reaches to here, we already passed reclaim per cgroup.
Yes if try_charge() failed we must do pre-cgroup reclaim.
> The cgroup may not at or reach limit but system has run out of physical
> EPC.
>
But after try_charge() we can still choose to reclaim from the current
On Wed, 3 Jan 2024 at 11:58, Hou Tao wrote:
>
> From: Hou Tao
>
> When trying to insert a 10MB kernel module kept in a virtiofs with cache
> disabled, the following warning was reported:
>
> [ cut here ]
> WARNING: CPU: 2 PID: 439 at mm/page_alloc.c:4544 ..
>
On Thu, Feb 22, 2024 at 10:23:41PM -0800, Randy Dunlap wrote:
> Extend the underline for a heading to prevent a documentation
> build warning. Also spell "reconnection" correctly.
>
> Documentation/userspace-api/vduse.rst:236: WARNING: Title underline too short.
> HOW VDUSE devices reconnectoin
On Thu, Feb 22, 2024 at 03:29:10PM -0500, Michael S. Tsirkin wrote:
> In a sense ... but on the other hand, the "fake DMA" metaphor seems to
> work surprisingly well, like in this instance - internal bounce buffer
> looks a bit like non-coherent DMA. A way to make this all prettier
> would I
35 matches
Mail list logo
