On 16.05.24 19:44, Guillaume Morin wrote:
On 02 May 5:59, Guillaume Morin wrote:
On 30 Apr 21:25, David Hildenbrand wrote:
I tried to get the hugepd stuff right but this was the first I heard
about it :-) Afaict follow_huge_pmd and friends were already DTRT
I'll have to have a closer look
On 02 May 5:59, Guillaume Morin wrote:
>
> On 30 Apr 21:25, David Hildenbrand wrote:
> > > I tried to get the hugepd stuff right but this was the first I heard
> > > about it :-) Afaict follow_huge_pmd and friends were already DTRT
> >
> > I'll have to have a closer look at some details (the
pcode_hugetlb(pte_t *ptep, unsigned long page_mask,
+ unsigned long vaddr,
+ unsigned long next, struct mm_walk *walk)
+{
+ struct uwo_data *data = walk->private;
+ const bool is_register = !!is_swbp_insn(>opcode);
+ pte_t pte = huge_ptep_get(ptep)
On 26.04.24 21:55, Guillaume Morin wrote:
On 26 Apr 9:19, David Hildenbrand wrote:
A couple of points:
a) Don't use page_mapcount(). Either folio_mapcount(), but likely you want
to check PageAnonExclusive.
b) If you're not following the can_follow_write_pte/_pmd model, you are
doing
n is that the previous __replace_page worked directly on the full
HP page so adjusting after gup seemed to make more sense to me. But
now I guess it's not that useful (esp we're going with a different
version of write_uprobe). I'll fix
(...)
> > {
> > struct uwo_data *dat
unsigned long next, struct mm_walk *walk)
+static int __write_opcode(pte_t *ptep, unsigned long vaddr,
+ unsigned long page_mask, struct mm_walk *walk)
Unrelated alignment change.
{
struct uwo_data *data = walk->private;;
const bool is_register =
t, struct mm_walk *walk)
+static int __write_opcode(pte_t *ptep, unsigned long vaddr,
+ unsigned long page_mask, struct mm_walk *walk)
{
struct uwo_data *data = walk->private;;
const bool is_register = !!is_swbp_insn(>opcode);
@@ -415,9 +417,12 @@ static int
VM_SHARED))
+ return false;
+
+ /* ... or read-only private ones */
+ if (!(vma->vm_flags & VM_MAYWRITE))
+ return false;
+
+ /* ... or already writable ones that just need to take a write fault */
+ if (vma->vm_flags & VM_WRITE)
+
, my patch seems to be working. The hugetlb code is pretty simple.
And it allows ptrace and the proc pid mem file to work on the executable
private hugetlb mappings.
There is one thing I am unclear about though. hugetlb enforces that
huge_pte_write() is true on FOLL_WRITE in both the fault
> be
> > > the cleaner thing to use here once I manage to switch over to
> > > FOLL_WRITE|FOLL_FORCE to break COW.
> >
> > Yes, my patch seems to be working. The hugetlb code is pretty simple.
> > And it allows ptrace and the proc pid mem file to work on the executa
and the proc pid mem file to work on the executable
private hugetlb mappings.
There is one thing I am unclear about though. hugetlb enforces that
huge_pte_write() is true on FOLL_WRITE in both the fault and
follow_page_mask paths. I am not sure if we can simply assume in the
hugetlb code
and the proc pid mem file to work on the executable
private hugetlb mappings.
There is one thing I am unclear about though. hugetlb enforces that
huge_pte_write() is true on FOLL_WRITE in both the fault and
follow_page_mask paths. I am not sure if we can simply assume in the
hugetlb code
ptrace and the proc pid mem file to work on the executable
private hugetlb mappings.
There is one thing I am unclear about though. hugetlb enforces that
huge_pte_write() is true on FOLL_WRITE in both the fault and
follow_page_mask paths. I am not sure if we can simply assume in the
hugetlb cod
On 24.04.24 22:44, Guillaume Morin wrote:
On 24 Apr 22:09, David Hildenbrand wrote:
Let me try to see if we can get this done cleaner.
One ugly part (in general here) is the custom page replacement in the
registration part.
We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing
On 24 Apr 22:09, David Hildenbrand wrote:
> > > Let me try to see if we can get this done cleaner.
> > >
> > > One ugly part (in general here) is the custom page replacement in the
> > > registration part.
> > >
> > > We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing
> > >
On 22.04.24 22:53, Guillaume Morin wrote:
On 22 Apr 20:59, David Hildenbrand wrote:
The benefit - to me - is very clear. People do use hugetlb mappings to
run code in production environments. The perf benefits are there for some
workloads. Intel has published a whitepaper about it etc.
Uprobes
On 22 Apr 20:59, David Hildenbrand wrote:
> > The benefit - to me - is very clear. People do use hugetlb mappings to
> > run code in production environments. The perf benefits are there for some
> > workloads. Intel has published a whitepaper about it etc.
> > Uprobes are a very good tool to do
wrote:
libhugetlbfs, the Intel iodlr code both allow to remap .text onto a
hugetlb private mapping. It's also pretty easy to do it manually.
One drawback of using this functionality is the lack of support for
uprobes (NOTE uprobe ignores shareable vmas)
This patch adds support for private hugetlb
Intel iodlr code both allow to remap .text onto a
> > hugetlb private mapping. It's also pretty easy to do it manually.
> > One drawback of using this functionality is the lack of support for
> > uprobes (NOTE uprobe ignores shareable vmas)
> >
> > This patch adds supp
he secpath that is shared
amongst segments. This lead to a situation where some segments are
not transformed correctly when segmentation happens at layer 3.
Fix this by using private skb extensions for segmented and hw offloaded
ESP packets.
Fixes: 94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion
he secpath that is shared
amongst segments. This lead to a situation where some segments are
not transformed correctly when segmentation happens at layer 3.
Fix this by using private skb extensions for segmented and hw offloaded
ESP packets.
Fixes: 94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion
Add folio_private() and set_folio_private() which mirror page_private()
and set_page_private() -- ie folio private data is the same as page
private data. The only difference is that these return a void *
instead of an unsigned long, which matches the majority of users.
Turn attach_page_private
On Fri, 9 Apr 2021, at 13:37, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:43AM CDT, Andrew Jeffery wrote:
> >Move all client-private data out of `struct kcs_bmc` into the KCS client
> >implementation.
> >
> >With this change the KCS BMC core code now only conce
On Fri, Mar 19, 2021 at 01:27:43AM CDT, Andrew Jeffery wrote:
>Move all client-private data out of `struct kcs_bmc` into the KCS client
>implementation.
>
>With this change the KCS BMC core code now only concerns itself with
>abstract `struct kcs_bmc` and `struct kcs_bmc_client` t
On Sat, Mar 20, 2021 at 10:41:56AM +0800, Lu Baolu wrote:
> drivers/iommu/intel/svm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
On Wed, Mar 31, 2021 at 07:47:10PM +0100, Matthew Wilcox (Oracle) wrote:
> Add folio_private() and set_folio_private() which mirror page_private()
> and set_page_private() -- ie folio private data is the same as page
> private data. The only difference is that these return a void *
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
this patchset replaces RT_PRINT_DATA private macro for dump hex values
with the kernel helper used for this pourpose.
-
Changes in v2:
- removed the do-nothing macro declaration as well
Fabio Aiuto (2):
staging: rtl8723bs: use print_hex_dump_debug
replace private macro RT_PRINT_DATA with in-kernel helper
print_hex_dump_debug
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/hal_com.c | 13 ---
drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c | 22 ++-
.../staging/rtl8723bs/hal/rtl8723b_hal_init.c
On Wed, Mar 31, 2021 at 11:34:05AM +0200, Fabio Aiuto wrote:
> this patchset replaces RT_PRINT_DATA private macro for dump hex values
> with the kernel helper used for this pourpose.
>
> Fabio Aiuto (2):
> staging: rtl8723bs: use print_hex_dump_debug instead of private
>
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
Add folio_private() and set_folio_private() which mirror page_private()
and set_page_private() -- ie folio private data is the same as page
private data. The only difference is that these return a void *
instead of an unsigned long, which matches the majority of users.
Turn attach_page_private
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
this patchset replace all RT_TRACE usages with public log functions
used for this pourpose
Fabio Aiuto (40):
staging: rtl8723bs: replace RT_TRACE with public printk wrappers in
core/rtw_xmit.c
staging: rtl8723bs: replace RT_TRACE with public printk wrappers in
core/rtw_security.c
replace private macro RT_PRINT_DATA with in-kernel helper
print_hex_dump_debug
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/hal_com.c | 13 ---
drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c | 22 ++-
.../staging/rtl8723bs/hal/rtl8723b_hal_init.c
this patchset replaces RT_PRINT_DATA private macro for dump hex values
with the kernel helper used for this pourpose.
Fabio Aiuto (2):
staging: rtl8723bs: use print_hex_dump_debug instead of private
RT_PRINT_DATA
staging: rtl8723bs: remove unused macro RT_PRINT_DATA
drivers/staging
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
Adding a header file for each subsystem - the connector
class, alt mode bus and the class for the muxes.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/bus.c | 2 ++
drivers/usb/typec/bus.h | 19 +-
drivers/usb/typec/class.c | 69 +++
> > CM3 won't use this interface till ethtool priv flag was set, it can be done
> > by
> communication over CM3 SRAM memory.
> >
> > > How does CM3 know the status of the link?
> >
> > CM3 has access to MAC registers and can read port status bit.
> >
> > > How does CM3 set its
> > > flow control
On Mon, Mar 22, 2021 at 03:59:43PM +, Stefan Chulski wrote:
>
> > > 2. CM3 code has very small footprint requirement, we cannot
> > > implement the complete Serdes and PHY infrastructure that kernel
> > > provides as part of CM3 application. Therefore I would like to
> > > continue relying
> > 2. CM3 code has very small footprint requirement, we cannot
> > implement the complete Serdes and PHY infrastructure that kernel
> > provides as part of CM3 application. Therefore I would like to
> > continue relying on kernel configuration for that.
>
> How can that work? How does Linux
This driver implements its own routines to allocate, access and free the
private data of its net_device. Use the functionality from the networking
core instead.
Signed-off-by: Martin Kaiser
---
drivers/staging/rtl8188eu/core/rtw_debug.c| 8 +-
drivers/staging/rtl8188eu/core/rtw_pwrctrl.c
Add folio_private() and set_folio_private() which mirror page_private()
and set_page_private() -- ie folio private data is the same as page
private data. The only difference is that these return a void *
instead of an unsigned long, which matches the majority of users.
Turn attach_page_private
The VT-d specification (section 7.6) requires that the value in the
Private Data field of a Page Group Response Descriptor must match
the value in the Private Data field of the respective Page Request
Descriptor.
The private data field of a page group response descriptor is set then
immediately
Move all client-private data out of `struct kcs_bmc` into the KCS client
implementation.
With this change the KCS BMC core code now only concerns itself with
abstract `struct kcs_bmc` and `struct kcs_bmc_client` types, achieving
expected separation of concerns. Further, the change clears the path
> 2. CM3 code has very small footprint requirement, we cannot
> implement the complete Serdes and PHY infrastructure that kernel
> provides as part of CM3 application. Therefore I would like to
> continue relying on kernel configuration for that.
How can that work? How does Linux know when CM3
a tail pointer cast to a folio is not going to
get very far, assuming CONFIG_DEBUG_VM_PGFLAGS is enabled (most distros
don't, but I do when I'm testing anything THPish).
These helpers aren't going to live for very long ... I expect to have
all filesystems which use attach/detach page private converted to foli
On Thu 18-03-21 11:02:17, Johannes Weiner wrote:
> On Thu, Mar 18, 2021 at 03:01:25PM +0100, Michal Hocko wrote:
> > On Wed 17-03-21 18:59:59, Shakeel Butt wrote:
> > > The function swap_readpage() (and other functions it call) extracts swap
> > > entry
On Wed, Mar 17, 2021 at 06:59:59PM -0700, Shakeel Butt wrote:
> The function swap_readpage() (and other functions it call) extracts swap
> entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
> skips the swapcache and thus we need to manually set the page->private
On Thu, Mar 18, 2021 at 03:01:25PM +0100, Michal Hocko wrote:
> On Wed 17-03-21 18:59:59, Shakeel Butt wrote:
> > The function swap_readpage() (and other functions it call) extracts swap
> > entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
> > skips t
On Wed 17-03-21 18:59:59, Shakeel Butt wrote:
> The function swap_readpage() (and other functions it call) extracts swap
> entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
> skips the swapcache and thus we need to manually set the page->private
> with the
On Wed, Mar 17, 2021 at 06:59:59PM -0700, Shakeel Butt wrote:
> The function swap_readpage() (and other functions it call) extracts swap
> entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
> skips the swapcache and thus we need to manually set the page->private
The function swap_readpage() (and other functions it call) extracts swap
entry from page->private. However for SWP_SYNCHRONOUS_IO, the kernel
skips the swapcache and thus we need to manually set the page->private
with the swap entry before calling swap_readpage().
Signed-off-by: Shakee
> +static inline void attach_page_private(struct page *page, void *data)
> +{
> + attach_folio_private((struct folio *)page, data);
> +}
> +
> +static inline void *detach_page_private(struct page *page)
> +{
> + return detach_folio_private((struct folio *)page);
> +}
I hate these open
gt; > > > From: Subbaraya Sundeep
> > > >
> > > > Memory for driver private structure rvu_devlink is
> > > > also allocated during devlink_alloc. Hence use
> > > > the allocated memory by devlink_alloc and access it
> > > > by devlink_priv call.
On Tue, 16 Mar 2021 23:33:40 +0530 sundeep subbaraya wrote:
> On Tue, Mar 16, 2021 at 10:53 PM Jakub Kicinski wrote:
> >
> > On Tue, 16 Mar 2021 14:57:07 +0530 Hariprasad Kelam wrote:
> > > From: Subbaraya Sundeep
> > >
> > > Memory for driver p
Hi Jakub,
On Tue, Mar 16, 2021 at 10:53 PM Jakub Kicinski wrote:
>
> On Tue, 16 Mar 2021 14:57:07 +0530 Hariprasad Kelam wrote:
> > From: Subbaraya Sundeep
> >
> > Memory for driver private structure rvu_devlink is
> > also allocated during devlink_alloc. Henc
On Tue, 16 Mar 2021 14:57:07 +0530 Hariprasad Kelam wrote:
> From: Subbaraya Sundeep
>
> Memory for driver private structure rvu_devlink is
> also allocated during devlink_alloc. Hence use
> the allocated memory by devlink_alloc and access it
> by devlink_priv call.
&g
> I really, really hope that someone has thought this through:
>
> Packet Processor I/O Interface (PPIO)
>
>The MUSDK PPIO driver provides low-level network interface API for
>User-Space network drivers/applications. The PPIO infrastrcuture maps
>Marvell's Packet Processor (PPv2)
On Tue, Mar 16, 2021 at 03:28:51PM +, Stefan Chulski wrote:
> No XDP doesn't require this. One of the use cases of the port reservation
> feature is the Marvell User Space SDK (MUSDK) which its latest code is
> publicly available here:
>
DP capable drivers having a
> flag like this. If this was required, i would expect it to be a common
> properly,
> not driver private.
No XDP doesn't require this. One of the use cases of the port reservation
feature is the Marvell User Space SDK (MUSDK) which its latest c
Notification private data is currently accessible via handle->notify_priv;
this data was indeed meant to be private to the notification core support
and not to be accessible by SCMI drivers: make it private hiding it inside
instance descriptor struct scmi_info and accessible only via dedica
From: Subbaraya Sundeep
Memory for driver private structure rvu_devlink is
also allocated during devlink_alloc. Hence use
the allocated memory by devlink_alloc and access it
by devlink_priv call.
Fixes: fae06da4("octeontx2-af: Add devlink suppoort to af driver")
Signed-off-by: Subbara
means the type of the private pointers varies
between control and monitor info dirs.
If the flags are RF_MON_INFO, its a struct rdt_resource. If the
flags are RF_CTRL_INFO, its a struct resctrl_schema. Nothing in
res_common_files[] has both flags.
Reviewed-by: Jamie Iles
Signed-off-by: James Morse
eflect the
>> right level of information.
>>
>> For the info dirs that represent a control, the information needed
>> is in the schema, as this is how the resource is being used. For the
>> monitors, its the resource as L3CODE_MON doesn't make sense, and would
>>
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro
On Thu, 11 Mar 2021 18:43:27 +0200 stef...@marvell.com wrote:
> According to Armada SoC architecture and design, all the PPv2 ports
> which are populated on the same communication processor silicon die
> (CP11x) share the same Classifier and Parser engines.
>
> Armada is an embedded platform and
e port, and the DT for the CM3
does. Linux never sees the port, since Linux should not be using it.
> or by user-space data plane application.
You mean XDP/AF_XDP? I don't see any other XDP capable drivers having
a flag like this. If this was required, i would expect it to be a
co
VED BIT(2)
/* Marvell tag types */
enum mvpp2_tag_type {
@@ -1251,6 +1252,9 @@ struct mvpp2_port {
/* Firmware TX flow control */
bool tx_fc;
+
+ /* private storage, allocated/used by Reserved/Normal mode toggling */
+ void *res_cfg;
};
/* The mvpp2_tx_d
> > From: Stefan Chulski
> >
> > According to Armada SoC architecture and design, all the PPv2 ports
> > which are populated on the same communication processor silicon die
> > (CP11x) share the same Classifier and Parser engines.
> >
> > Armada is an embedded platform and therefore there is a
On Wed, Mar 10, 2021 at 11:42:09AM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> According to Armada SoC architecture and design, all the PPv2 ports
> which are populated on the same communication processor silicon die
> (CP11x) share the same Classifier and Parser engines.
>
>
> Make it patch series? I can split it to 2/3 patches.
I don't think that will be needed. The helpers should be pretty
obvious.
Andrew
> k...@kernel.org; li...@armlinux.org.uk; m...@semihalf.com;
> rmk+ker...@armlinux.org.uk; aten...@kernel.org; rab...@solid-run.com
> Subject: [EXT] Re: [net-next] net: mvpp2: Add reserved port private flag
> configuration
>
> External Email
>
> --
> static void mvpp2_ethtool_get_strings(struct net_device *netdev, u32 sset,
> u8 *data)
> {
> struct mvpp2_port *port = netdev_priv(netdev);
> int i, q;
>
> - if (sset != ETH_SS_STATS)
> - return;
> + switch (sset) {
> +
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro
MVPP22_F_IF_RESERVED BIT(2)
/* Marvell tag types */
enum mvpp2_tag_type {
@@ -1251,6 +1252,9 @@ struct mvpp2_port {
/* Firmware TX flow control */
bool tx_fc;
+
+ /* private storage, allocated/used by Reserved/Normal mode toggling */
+ void *res_cfg
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro
On 3/1/21 9:21 PM, Daniel Lezcano wrote:
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure
On Mon, Mar 08, 2021 at 06:12:29AM +, Sudeep Holla wrote:
> On Tue, Feb 02, 2021 at 10:15:53PM +, Cristian Marussi wrote:
> > Notification private data is currently accessible via handle->notify_priv;
> > this data was indeed meant to be private to the notific
On Tue, Feb 02, 2021 at 10:15:53PM +, Cristian Marussi wrote:
> Notification private data is currently accessible via handle->notify_priv;
> this data was indeed meant to be private to the notification core support
> and not to be accessible by SCMI drivers: make it private hidi
Add folio_private() and set_folio_private() which mirror page_private()
and set_page_private() -- ie folio private data is the same as page
private data.
Turn attach_page_private() into attach_folio_private() and reimplement
attach_page_private() as a wrapper. No filesystem which uses page
The dtpm framework provides an API to allocate a dtpm node. However
when a backend dtpm driver needs to allocate a dtpm node it must
define its own structure and store the pointer of this structure in
the private field of the dtpm structure.
It is more elegant to use the container_of macro
sc_cm_id->event_handler = svc_rdma_cma_handler;
-
/* Construct RDMA-CM private message */
pmsg.cp_magic = rpcrdma_cmp_magic;
pmsg.cp_version = RPCRDMA_CMP_VERSION;
@@ -498,7 +495,10 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt
*xprt)
}
From: Dave Jiang
[ Upstream commit c06e424be5f5184468c5f761c0d2cf1ed0a4e0fc ]
Add DMA_PRIVATE attribute flag to idxd DMA channels. The dedicated WQs are
expected to be used by a single client and not shared. While doing NTB
testing this mistake was discovered, which prevented ntb_transport from
From: Dave Jiang
[ Upstream commit c06e424be5f5184468c5f761c0d2cf1ed0a4e0fc ]
Add DMA_PRIVATE attribute flag to idxd DMA channels. The dedicated WQs are
expected to be used by a single client and not shared. While doing NTB
testing this mistake was discovered, which prevented ntb_transport from
sc_cm_id->event_handler = svc_rdma_cma_handler;
-
/* Construct RDMA-CM private message */
pmsg.cp_magic = rpcrdma_cmp_magic;
pmsg.cp_version = RPCRDMA_CMP_VERSION;
@@ -498,7 +495,10 @@ static struct svc_xprt *svc_rdma_accept(struct svc_xprt
*xprt)
}
When an IOASID set is used for guest SVA, each VM will acquire its
ioasid_set for IOASID allocations. IOASIDs within the VM must have a
host/physical IOASID backing, mapping between guest and host IOASIDs can
be non-identical. IOASID set private ID (SPID) is introduced in this
patch to be used
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
Move all client-private data out of `struct kcs_bmc` into the KCS client
implementation.
With this change the KCS BMC core code now only concerns itself with
abstract `struct kcs_bmc` and `struct kcs_bmc_client` types, achieving
expected separation of concerns. Further, the change clears the path
This is a bit of a tidy-up, but also helps with extending the
iioutils_get_type() function a bit, as we don't need to use it outside of
the iio_utils.c file. So, we'll need to update it only in one place.
With this change, the 'unsigned' types are updated to 'unsigned int' in the
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
From: Dave Wysochanski
[ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
Remove duplicated helper functions to parse opaque XDR objects
and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
In the new file carry the license and copyright from the source file
This is a bit of a tidy-up, but also helps with extending the
iioutils_get_type() function a bit, as we don't need to use it outside of
the iio_utils.c file. So, we'll need to update it only in one place.
With this change, the 'unsigned' types are updated to 'unsigned int' in the
On Wed, Feb 10, 2021 at 02:40:10PM +1100, Alistair Popple wrote:
> On Wednesday, 10 February 2021 12:39:32 AM AEDT Jason Gunthorpe wrote:
> > On Tue, Feb 09, 2021 at 12:07:14PM +1100, Alistair Popple wrote:
> > > Device private pages are used to represent device memory that is
This is a bit of a tidy-up, but also helps with extending the
iioutils_get_type() function a bit, as we don't need to use it outside of
the iio_utils.c file. So, we'll need to update it only in one place.
With this change, the 'unsigned' types are updated to 'unsigned int' in the
1 - 100 of 5671 matches
Mail list logo
