Now, we chain the pages of big mode by the page's private variable.
But a subsequent patch aims to make the big mode to support
premapped mode. This requires additional space to store the dma addr.
Within the sub-struct that contains the 'private', there is no suitable
variable
Now, we chain the pages of big mode by the page's private variable.
But a subsequent patch aims to make the big mode to support
premapped mode. This requires additional space to store the dma addr.
Within the sub-struct that contains the 'private', there is no suitable
variable
t;>>> On Mon, Apr 15, 2024 at 10:35 AM Xuan Zhuo
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Fri, 12 Apr 2024 13:49:12 +0800, Jason Wang
> >>>>>>>>> wrote:
> >>&
On Thu, Apr 18, 2024 at 10:19:33PM +0200, Jesper Dangaard Brouer wrote:
> I'm not sure it is "fine" to, explicitly choosing not to use page pool,
> and then (ab)use `struct page` member (pp) that intended for page_pool
> for other stuff. (In this case create a linked list of pages).
>
> +#define
2024 12:47:55 +0800, Jason Wang wrote:
On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo wrote:
Now, we chain the pages of big mode by the page's private variable.
But a subsequent patch aims to make the big mode to support
premapped mode. This requires additional space to store the dma addr.
W
On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo wrote:
>
> Now, we chain the pages of big mode by the page's private variable.
> But a subsequent patch aims to make the big mode to support
> premapped mode. This requires additional space to store the dma addr.
>
> Within the s
24 13:49:12 +0800, Jason Wang
> > > > > > > > > > wrote:
> > > > > > > > > > > On Fri, Apr 12, 2024 at 1:39 PM Xuan Zhuo
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
t 1:39 PM Xuan Zhuo
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 12 Apr 2024 12:47:55 +0800, Jason Wang
> > > > > > > > >
t; > > > > wrote:
> > > > > > > > > On Fri, Apr 12, 2024 at 1:39 PM Xuan Zhuo
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri,
M Xuan Zhuo
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Fri, 12 Apr 2024 12:47:55 +0800, Jason Wang
> > > > > > > > > wrote:
> > > > > > > > > > On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo
gt; > > > > wrote:
> > > > > > > On Fri, Apr 12, 2024 at 1:39 PM Xuan Zhuo
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Fri, 12 Apr 2024 12:47:55 +0800, Jason Wa
; > > > wrote:
> > > > > > >
> > > > > > > On Fri, 12 Apr 2024 12:47:55 +0800, Jason Wang
> > > > > > > wrote:
> > > > > > > > On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo
> > > > > &
> > > > > wrote:
> > > > > > > On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Now, we chain the pages of big mode by the page's private
> > > On Fri, Apr 12, 2024 at 1:39 PM Xuan Zhuo
> > > > wrote:
> > > > >
> > > > > On Fri, 12 Apr 2024 12:47:55 +0800, Jason Wang
> > > > > wrote:
> > > > > > On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhu
> > On Fri, 12 Apr 2024 12:47:55 +0800, Jason Wang
> > > > wrote:
> > > > > On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo
> > > > > wrote:
> > > > > >
> > > > > > Now, we chain the pages of big mode by the pag
> > > On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo
> > > > wrote:
> > > > >
> > > > > Now, we chain the pages of big mode by the page's private variable.
> > > > > But a subsequent patch aims to make the big mode to support
> &g
> > > Now, we chain the pages of big mode by the page's private variable.
> > > > But a subsequent patch aims to make the big mode to support
> > > > premapped mode. This requires additional space to store the dma addr.
> > > >
> > > > Wit
> > > Now, we chain the pages of big mode by the page's private variable.
> > > > But a subsequent patch aims to make the big mode to support
> > > > premapped mode. This requires additional space to store the dma addr.
> > > >
> > > > Wit
On Fri, Apr 12, 2024 at 1:39 PM Xuan Zhuo wrote:
>
> On Fri, 12 Apr 2024 12:47:55 +0800, Jason Wang wrote:
> > On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo
> > wrote:
> > >
> > > Now, we chain the pages of big mode by the page's private variable.
> >
On Fri, 12 Apr 2024 12:47:55 +0800, Jason Wang wrote:
> On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo wrote:
> >
> > Now, we chain the pages of big mode by the page's private variable.
> > But a subsequent patch aims to make the big mode to support
> > premapped mode
On Thu, Apr 11, 2024 at 10:51 AM Xuan Zhuo wrote:
>
> Now, we chain the pages of big mode by the page's private variable.
> But a subsequent patch aims to make the big mode to support
> premapped mode. This requires additional space to store the dma addr.
>
> Within the s
Now, we chain the pages of big mode by the page's private variable.
But a subsequent patch aims to make the big mode to support
premapped mode. This requires additional space to store the dma addr.
Within the sub-struct that contains the 'private', there is no suitable
variable
I have a client who wants to invest $275 Million in your country, a
Russian billionaire, she is looking for partner (investment manager)
for a period of 10 to 20 years.
From: Vladimir Oltean
One thing became visible when writing the blamed commit, and that was
that STP and PTP frames injected by net/dsa/tag_sja1105.c using the
deferred xmit mechanism are always classified to the pvid of the CPU
port, regardless of whatever VLAN there might be in these packets.
From: Mustafa Ismail
Register auxiliary drivers which can attach to auxiliary RDMA
devices from Intel PCI netdev drivers i40e and ice. Implement the private
channel ops, and register net notifiers.
Signed-off-by: Mustafa Ismail
Signed-off-by: Shiraz Saleem
---
drivers/infiniband/hw/irdma
From: Mustafa Ismail
Register auxiliary drivers which can attach to auxiliary RDMA
devices from Intel PCI netdev drivers i40e and ice. Implement the private
channel ops, and register net notifiers.
Signed-off-by: Mustafa Ismail
Signed-off-by: Shiraz Saleem
---
drivers/infiniband/hw/irdma
ransformed 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 in IPsec crypto
offload.")
Signed-off-by: Steffen Klassert
---
net/ipv4
From: Mustafa Ismail
Register auxiliary drivers which can attach to auxiliary RDMA
devices from Intel PCI netdev drivers i40e and ice. Implement the private
channel ops, and register net notifiers.
Signed-off-by: Mustafa Ismail
Signed-off-by: Shiraz Saleem
---
drivers/infiniband/hw/irdma
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
ransformed 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 in IPsec crypto
offload.")
Signed-off-by: Steffen Klassert
---
net/ipv4
ffload. This flag is set on the 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
&g
On Wed, Mar 24, 2021 at 11:46:42PM +, Saleem, Shiraz wrote:
> > Subject: Re: [PATCH v2 08/23] RDMA/irdma: Register auxiliary driver and
> > implement private channel OPs
> >
> > On Wed, Mar 24, 2021 at 04:17:20PM +0200, Leon Romanovsky wrote:
> > > On Wed,
> Subject: Re: [PATCH v2 08/23] RDMA/irdma: Register auxiliary driver and
> implement private channel OPs
>
> On Wed, Mar 24, 2021 at 04:17:20PM +0200, Leon Romanovsky wrote:
> > On Wed, Mar 24, 2021 at 11:00:46AM -0300, Jason Gunthorpe wrote:
> > > On Wed, Mar 24, 202
> > From: Mustafa Ismail
> > > >
> > > > Register auxiliary drivers which can attach to auxiliary RDMA
> > > > devices from Intel PCI netdev drivers i40e and ice. Implement the
> > > > private
> > > > channel ops, and register ne
rivers which can attach to auxiliary RDMA
> > > devices from Intel PCI netdev drivers i40e and ice. Implement the private
> > > channel ops, and register net notifiers.
> > >
> > > Signed-off-by: Mustafa Ismail
> > > Signed-off-by: Shiraz Saleem
i40e and ice. Implement the private
> > channel ops, and register net notifiers.
> >
> > Signed-off-by: Mustafa Ismail
> > Signed-off-by: Shiraz Saleem
> > drivers/infiniband/hw/irdma/i40iw_if.c | 229 +
> > drivers/infiniband/hw/irdma/main.c
On Tue, Mar 23, 2021 at 06:59:52PM -0500, Shiraz Saleem wrote:
> From: Mustafa Ismail
>
> Register auxiliary drivers which can attach to auxiliary RDMA
> devices from Intel PCI netdev drivers i40e and ice. Implement the private
> channel ops, and register net notifiers.
>
From: Mustafa Ismail
Register auxiliary drivers which can attach to auxiliary RDMA
devices from Intel PCI netdev drivers i40e and ice. Implement the private
channel ops, and register net notifiers.
Signed-off-by: Mustafa Ismail
Signed-off-by: Shiraz Saleem
---
drivers/infiniband/hw/irdma
Bjorn Helgaas writes:
> On Mon, Mar 22, 2021 at 09:18:20AM -0700, Vinicius Costa Gomes wrote:
>> Make pci_enable_ptm() accessible from the drivers.
>>
>> Even if PTM still works on the platform I am using without calling
>> this function, it might be possible that it's not always the case.
>
> I
On Mon, Mar 22, 2021 at 09:18:20AM -0700, Vinicius Costa Gomes wrote:
> Make pci_enable_ptm() accessible from the drivers.
>
> Even if PTM still works on the platform I am using without calling
> this function, it might be possible that it's not always the case.
I don't understand the value of th
On Tue, Mar 23, 2021 at 11:40:11AM -0700, Vinicius Costa Gomes wrote:
> > Without an EXPORT_SYMBOL_GPL this is not going to be very useful for
> > your driver.
>
> Unless I am missing something here, the commit that made
> 'pci_enable_ptm()' private didn't
>
>> Signed-off-by: Vinicius Costa Gomes
>> Acked-by: Bjorn Helgaas
>
> Without an EXPORT_SYMBOL_GPL this is not going to be very useful for
> your driver.
Unless I am missing something here, the commit that made
'pci_enable_ptm()' private didn't remove the 'EXPORT_SYMBOL' from the
function definition in drivers/pci/pcie/ptm.c.
Cheers,
--
Vinicius
On Mon, Mar 22, 2021 at 09:18:20AM -0700, Vinicius Costa Gomes wrote:
> Make pci_enable_ptm() accessible from the drivers.
>
> Even if PTM still works on the platform I am using without calling
> this function, it might be possible that it's not always the case.
>
> Exposing this to the driver en
d 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 in IPsec
ransformed 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 in IPsec crypto
offload.")
Signed-off-by: Steffen Klassert
---
include/linux/s
> > 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 d
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
Make pci_enable_ptm() accessible from the drivers.
Even if PTM still works on the platform I am using without calling
this function, it might be possible that it's not always the case.
Exposing this to the driver enables the driver to use the
'ptm_enabled' field of 'pci_dev' to check if PTM is en
> > 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
> 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 has
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. Hence u
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) co
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:
> https://github.com/MarvellEmbeddedProcessors/musdk-marv
her XDP 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
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
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 t
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
ne 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;
};
> > 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 nee
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.
>
> Ar
> 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) {
> + c
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
On Mon, Feb 08, 2021 at 05:03:30PM +0300, Serge Semin wrote:
> There has been no user of the denoted array of the device private data
> since commit e7f4dc3536a4 ("mdio: Move allocation of interrupts into
> core"). Discard it then.
>
> Signed-off-by: Serge Semin
There has been no user of the denoted array of the device private data
since commit e7f4dc3536a4 ("mdio: Move allocation of interrupts into
core"). Discard it then.
Signed-off-by: Serge Semin
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 -
1 file changed, 1 deletion(-)
di
Alexander Lobakin wrote:
> Now we can remove a bunch of identical functions from the drivers and
> make them use common dev_page_is_reusable(). All {,un}likely() checks
> are omitted since it's already present in this helper.
> Also update some comments near the call sites.
>
> Suggested-by: Davi
On Tue, Feb 02, 2021 at 07:42:11PM +, Saleem, Shiraz wrote:
> > > Only loosely following the arguments here, but one of the requirements
> > > of the driver-op scheme is that the notifying agent needs to know the
> > > target device. With the notifier-chain approach the target device
> > > bec
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Mon, Feb 01, 2021 at 05:06:58PM -0800, Dan Williams wrote:
> > On Mon, Feb 1, 2021 at 4:40 PM Saleem, Shiraz
> wrote:
> > >
> > > > Subje
On Mon, Feb 01, 2021 at 05:06:58PM -0800, Dan Williams wrote:
> On Mon, Feb 1, 2021 at 4:40 PM Saleem, Shiraz wrote:
> >
> > > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> > > implement private channel OPs
> > >
> > > On
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
net/sunrpc/au
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
net/sunrpc/au
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
net/sunrpc/au
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
net/sunrpc/au
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
net/sunrpc/au
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
net/sunrpc/au
Now we can remove a bunch of identical functions from the drivers and
make them use common dev_page_is_reusable(). All {,un}likely() checks
are omitted since it's already present in this helper.
Also update some comments near the call sites.
Suggested-by: David Rientjes
Suggested-by: Jakub Kicins
On Mon, Feb 1, 2021 at 4:40 PM Saleem, Shiraz wrote:
>
> > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> > implement private channel OPs
> >
> > On Sat, Jan 30, 2021 at 01:19:36AM +, Saleem, Shiraz wrote:
> > > > Subject: Re
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Sat, Jan 30, 2021 at 01:19:36AM +, Saleem, Shiraz wrote:
> > > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver
> > > and
On Wed, Jan 27, 2021 at 12:41:41AM +, Saleem, Shiraz wrote:
> > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> > implement private channel OPs
> >
> > On Tue, Jan 26, 2021 at 12:42:16AM +, Saleem, Shiraz wrote:
> >
> > &g
On Sat, Jan 30, 2021 at 01:19:22AM +, Saleem, Shiraz wrote:
> Do you mean 2 different auxiliary device names - one for RoCE and
> iWARP? The drv.probe() and other callbacks will be very similar for
> gen2, so one gen2 aux driver which can bind to iW and RoCE aux
> device should suffice.
You
On Sat, Jan 30, 2021 at 01:19:36AM +, Saleem, Shiraz wrote:
> > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> > implement private channel OPs
> >
> > On Wed, Jan 27, 2021 at 07:16:41PM -0400, Jason Gunthorpe wrote:
> > > On Wed,
On Sat, Jan 30, 2021 at 01:19:36AM +, Saleem, Shiraz wrote:
> > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> > implement private channel OPs
> >
> > On Wed, Jan 27, 2021 at 07:16:41PM -0400, Jason Gunthorpe wrote:
> > > On Wed,
Now we can remove a bunch of identical functions from the drivers and
make them use common dev_page_is_reusable(). All {,un}likely() checks
are omitted since it's already present in this helper.
Also update some comments near the call sites.
Suggested-by: David Rientjes
Suggested-by: Jakub Kicins
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Mon, Jan 25, 2021 at 02:42:48PM -0400, Jason Gunthorpe wrote:
> > On Fri, Jan 22, 2021 at 05:48:12PM -0600, Shiraz Saleem wrote:
> > > +/**
> > > +
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Wed, Jan 27, 2021 at 07:16:41PM -0400, Jason Gunthorpe wrote:
> > On Wed, Jan 27, 2021 at 10:17:56PM +, Saleem, Shiraz wrote:
> >
> > > Even wi
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Wed, Jan 27, 2021 at 12:42:09AM +, Saleem, Shiraz wrote:
>
> > > It does, the PCI driver is not supposed to spawn any aux devices for
> > >
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Fri, Jan 22, 2021 at 05:48:12PM -0600, Shiraz Saleem wrote:
>
> > +static int irdma_probe(struct auxiliary_device *aux_dev,
> > + const str
On Wed, Jan 27, 2021 at 07:16:41PM -0400, Jason Gunthorpe wrote:
> On Wed, Jan 27, 2021 at 10:17:56PM +, Saleem, Shiraz wrote:
>
> > Even with another core PCI driver, there still needs to be private
> > communication channel between the aux rdma driver and this PCI
> &g
On Wed, Jan 27, 2021 at 10:17:56PM +, Saleem, Shiraz wrote:
> Even with another core PCI driver, there still needs to be private
> communication channel between the aux rdma driver and this PCI
> driver to pass things like QoS updates.
Data pushed from the core driver to its au
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Wed, Jan 27, 2021 at 12:41:41AM +, Saleem, Shiraz wrote:
> > > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver
> > > and
On Mon, Jan 25, 2021 at 05:01:40PM -0800, Jacob Keller wrote:
>
>
> On 1/25/2021 4:39 PM, Saleem, Shiraz wrote:
> >> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> >> implement private channel OPs
> >>
> >> On Sun, Jan 24, 20
On Mon, Jan 25, 2021 at 02:42:48PM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 22, 2021 at 05:48:12PM -0600, Shiraz Saleem wrote:
> > +/**
> > + * irdma_init_dev - GEN_2 device init
> > + * @aux_dev: auxiliary device
> > + *
> > + * Create device resources, set up queues, pble and hmc objects.
> >
On Wed, Jan 27, 2021 at 12:41:41AM +, Saleem, Shiraz wrote:
> > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> > implement private channel OPs
> >
> > On Tue, Jan 26, 2021 at 12:42:16AM +, Saleem, Shiraz wrote:
> >
> > > I
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Tue, Jan 26, 2021 at 12:42:16AM +, Saleem, Shiraz wrote:
>
> > I think this essentially means doing away with .open/.close piece.
>
> Yes, that too, a
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
> On Mon, Jan 25, 2021 at 05:01:40PM -0800, Jacob Keller wrote:
> >
> >
> > On 1/25/2021 4:39 PM, Saleem, Shiraz wrote:
> > >> Subject: Re: [PATC
> Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> implement private channel OPs
>
>
>
> On 1/25/2021 9:29 PM, Leon Romanovsky wrote:
> > On Mon, Jan 25, 2021 at 05:01:40PM -0800, Jacob Keller wrote:
> >>
> >>
>
1 - 100 of 640 matches
Mail list logo
