* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Andrew Lunn @ 2018-03-29 14:40 UTC (permalink / raw)
To: Alexandre Belloni
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180329140544.GB12066@piout.net>
On Thu, Mar 29, 2018 at 04:05:44PM +0200, Alexandre Belloni wrote:
> On 23/03/2018 at 21:49:39 +0100, Andrew Lunn wrote:
> > On Fri, Mar 23, 2018 at 09:11:12PM +0100, Alexandre Belloni wrote:
> > > Add a driver for the Microsemi MII Management controller (MIIM) found on
> > > Microsemi SoCs.
> > > On Ocelot, there are two controllers, one is connected to the internal
> > > PHYs, the other one can communicate with external PHYs.
> >
> > Hi Alexandre
> >
> > This looks to be standalone. Such drivers we try to put in
> > drivers/net/phy.
> >
> > > +static int mscc_miim_read(struct mii_bus *bus, int mii_id, int regnum)
> > > +{
> > > + struct mscc_miim_dev *miim = bus->priv;
> > > + u32 val;
> > > + int ret;
> > > +
> > > + mutex_lock(&miim->lock);
> >
> > What are you locking against here?
> >
> > And you don't appear to initialize the mutex anywhere.
> >
> > > +static int mscc_miim_reset(struct mii_bus *bus)
> > > +{
> > > + struct mscc_miim_dev *miim = bus->priv;
> > > + int i;
> > > +
> > > + if (miim->phy_regs) {
> > > + writel(0, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > > + writel(0x1ff, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > > + mdelay(500);
> > > + }
> > > +
> > > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > > + bus->phy_mask |= BIT(i);
> > > + }
> >
> > Why do this? Especially so for the external bus, where the PHYs might
> > have a GPIO reset line, and won't respond until the gpio is
> > released. The core code does that just before it scans the bus, or
> > just before it scans the particular address on the bus, depending on
> > the scope of the GPIO.
> >
>
> IIRC, this was needed when probing the bus without DT, in that case, the
> mdiobus_scan loop of __mdiobus_register() will fail when doing the
> get_phy_id for phys 0 to 31 because get_phy_id() transforms any error in
> -EIO and so it is impossible to register the bus. Other drivers have a
> similar code to handle that case.
Hi Alexandre
Do you mean mscc_miim_read() will return -EIO if there is no device on
the bus at the address trying to be read? Most devices just return
0xffff because there is a pull up on the data line, nothing is driving
it, so all 1's are read.
It sounds like the correct fix is for get_phy_id() to look at the
error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and
maybe ENODEV, set *phy_id to 0xffffffff and return. The scan code
should then do the correct thing.
Andrew
^ permalink raw reply
* Re: [PATCH 000/109] remove in-kernel calls to syscalls
From: Dominik Brodowski @ 2018-03-29 14:42 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-kernel, viro, torvalds, arnd, linux-arch, hmclauchlan,
tautschn, Amir Goldstein, Andi Kleen, Andrew Morton,
Christoph Hellwig, Darren Hart, David S . Miller,
Eric W . Biederman, H . Peter Anvin, Ingo Molnar, Jaswinder Singh,
Jeff Dike, Jiri Slaby, kexec, linux-fsdevel, linux-mm, linux-s390,
Luis R . Rodriguez, netdev
In-Reply-To: <20180329142027.GA24860@bombadil.infradead.org>
On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > onwards to not call system call functions in the kernel: It is better to
> > use use a different calling convention for system calls there, where
> > struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands
> > processing over to the actual syscall function. This means that only those
> > parameters which are actually needed for a specific syscall are passed on
> > during syscall entry, instead of filling in six CPU registers with random
> > user space content all the time (which may cause serious trouble down the
> > call chain).[*]
>
> How do we stop new ones from springing up? Some kind of linker trick
> like was used to, er, "dissuade" people from using gets()?
Once the patches which modify the syscall calling convention are merged,
it won't compile on 64-bit x86, but bark loudly. That should frighten anyone.
Meow.
Thanks,
Dominik
^ permalink raw reply
* Re: [PATCH net] vhost: validate log when IOTLB is enabled
From: Michael S. Tsirkin @ 2018-03-29 14:44 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <1522310404-8486-1-git-send-email-jasowang@redhat.com>
On Thu, Mar 29, 2018 at 04:00:04PM +0800, Jason Wang wrote:
> Vq log_base is the userspace address of bitmap which has nothing to do
> with IOTLB. So it needs to be validated unconditionally otherwise we
> may try use 0 as log_base which may lead to pin pages that will lead
> unexpected result (e.g trigger BUG_ON() in set_bit_to_user()).
>
> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
> Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
> Signed-off-by: Jason Wang <jasowang@redhat.com>
One follow-up question:
We still observe that get user pages returns 0 sometimes. While I agree
we should not pass in unvalidated addresses, isn't this worth
documenting?
> ---
> drivers/vhost/vhost.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 5d5a9d9..5320039 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1244,14 +1244,12 @@ static int vq_log_access_ok(struct vhost_virtqueue *vq,
> /* Caller should have vq mutex and device mutex */
> int vhost_vq_access_ok(struct vhost_virtqueue *vq)
> {
> - if (vq->iotlb) {
> - /* When device IOTLB was used, the access validation
> - * will be validated during prefetching.
> - */
> - return 1;
> - }
> - return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used) &&
> - vq_log_access_ok(vq, vq->log_base);
> + int ret = vq_log_access_ok(vq, vq->log_base);
> +
> + if (ret || vq->iotlb)
> + return ret;
> +
> + return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used);
> }
> EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
>
> --
> 2.7.4
^ permalink raw reply
* RE: [PATCH 000/109] remove in-kernel calls to syscalls
From: David Laight @ 2018-03-29 14:46 UTC (permalink / raw)
To: 'Dominik Brodowski', Matthew Wilcox
Cc: linux-kernel@vger.kernel.org, viro@ZenIV.linux.org.uk,
torvalds@linux-foundation.org, arnd@arndb.de,
linux-arch@vger.kernel.org, hmclauchlan@fb.com,
tautschn@amazon.co.uk, Amir Goldstein, Andi Kleen, Andrew Morton,
Christoph Hellwig, Darren Hart, David S . Miller,
Eric W . Biederman, H . Peter Anvin, Ingo Molnar, Jaswinder Singh,
Jeff Dike <jdik
In-Reply-To: <20180329144209.GA25559@isilmar-4.linta.de>
From: Dominik Brodowski
> Sent: 29 March 2018 15:42
> On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > > onwards to not call system call functions in the kernel: It is better to
> > > use use a different calling convention for system calls there, where
> > > struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands
> > > processing over to the actual syscall function. This means that only those
> > > parameters which are actually needed for a specific syscall are passed on
> > > during syscall entry, instead of filling in six CPU registers with random
> > > user space content all the time (which may cause serious trouble down the
> > > call chain).[*]
> >
> > How do we stop new ones from springing up? Some kind of linker trick
> > like was used to, er, "dissuade" people from using gets()?
>
> Once the patches which modify the syscall calling convention are merged,
> it won't compile on 64-bit x86, but bark loudly. That should frighten anyone.
> Meow.
Should be pretty easy to ensure the prototypes aren't in any normal header.
Renaming the global symbols (to not match the function name) will make it
much harder to call them as well.
David
^ permalink raw reply
* Re: [net-next, v2, 01/10] soc: ti: K2G: enhancement to support QMSS in NSS
From: Murali Karicheri @ 2018-03-29 14:50 UTC (permalink / raw)
To: Grygorii Strashko, robh+dt, ssantosh, malat, w-kwok2, devicetree,
linux-kernel, linux-arm-kernel, davem, netdev
Cc: mark.rutland
In-Reply-To: <1ccf03e7-17b4-cf00-176d-0e41038c88f8@ti.com>
Hi Grygorii,
Thanks for reviewing this!
On 03/28/2018 03:01 PM, Grygorii Strashko wrote:
> Hi Murali,
>
> On 03/27/2018 11:31 AM, Murali Karicheri wrote:
>> Navigator Subsystem (NSS) available on K2G SoC has a cut down
>> version of QMSS with less number of queues, internal linking ram
>> with lesser number of buffers etc. It doesn't have status and
>> explicit push register space as in QMSS available on other K2 SoCs.
>> So define reg indices specific to QMSS on K2G. This patch introduces
>> "keystone-navigator-qmss-l" compatibility to identify QMSS on
>> K2G NSS (QMSS Lite) and to customize the dts handling code. Per
>> Device manual, descriptors with index less than or equal to
>> regions0_size is in region 0 in the case of QMSS where as for
>> QMSS Lite, descriptors with index less than regions0_size is in
>> region 0. So update the size accordingly in the regions0_size bits
>> of the linking ram size 0 register.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
>> ---
>> .../bindings/soc/ti/keystone-navigator-qmss.txt | 7 ++
>> drivers/soc/ti/knav_qmss.h | 6 ++
>> drivers/soc/ti/knav_qmss_queue.c | 90 ++++++++++++++++------
>> 3 files changed, 81 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
>> index 77cd42c..1b0878a 100644
>> --- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
>> +++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
>> @@ -18,6 +18,7 @@ pool management.
>>
>> Required properties:
>> - compatible : Must be "ti,keystone-navigator-qmss";
>> + : Must be "ti,keystone-navigator-qmss-l" for NSS Lite
>
>
> I think, It will be more accurate to add K2G specific compat string
> like "ti,66ak2g-navss-qm":
>
> compatible = "ti,66ak2g-navss-qm", "ti,keystone-navigator-qmss";
>
> because 66ak2g TRM doesn't mention "Navss light" and this Navss version is used
> only in 66ak2g Soc. As result, 66ak2g Navss QM is subset of of keystone 2 Navss QM
> which should be defined in DT by adding more specific compat string in addition
> to generic one.
>
As I have mentioned in the commit description, it is not a subset of the K2
registers. There are some differences that makes it not compatible with K2 QMSS.
See my description,
>>It doesn't have status and explicit push register space as in QMSS available on
>>other K2 SoCs.
And also
>> Per Device manual, descriptors with index less than or equal to
>> regions0_size is in region 0 in the case of QMSS where as for
>> QMSS Lite, descriptors with index less than regions0_size is in
>> region 0. So update the size accordingly in the regions0_size bits
>> of the linking ram size 0 register
So will have to use a specific compatible = "ti,66ak2g-navss-qm" for this QM IMO.
Murali
>
>> - clocks : phandle to the reference clock for this device.
>> - queue-range : <start number> total range of queue numbers for the device.
>> - linkram0 : <address size> for internal link ram, where size is the total
>> @@ -39,6 +40,12 @@ Required properties:
>> - Descriptor memory setup region.
>> - Queue Management/Queue Proxy region for queue Push.
>> - Queue Management/Queue Proxy region for queue Pop.
>> +
>> +For NSS lite, following QMSS reg indexes are used in that order
>
> For 66AK2G NAVSS QM..
>
>> + - Queue Peek region.
>> + - Queue configuration region.
>> + - Queue Management/Queue Proxy region for queue Push/Pop.
>> +
>> - queue-pools : child node classifying the queue ranges into pools.
>> Queue ranges are grouped into 3 type of pools:
>> - qpend : pool of qpend(interruptible) queues
>> diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
>> index 905b974..5fa1ce6 100644
>> --- a/drivers/soc/ti/knav_qmss.h
>> +++ b/drivers/soc/ti/knav_qmss.h
>> @@ -292,6 +292,11 @@ struct knav_queue {
>> struct list_head list;
>> };
>>
>> +enum qmss_version {
>> + QMSS,
>> + QMSS_LITE,
>
> QMSS_66AK2G
>
>> +};
>> +
>> struct knav_device {
>> struct device *dev;
>> unsigned base_id;
>> @@ -305,6 +310,7 @@ struct knav_device {
>> struct list_head pools;
>> struct list_head pdsps;
>> struct list_head qmgrs;
>> + enum qmss_version version;
>> };
>>
>
> [...]
>
>> }
>>
>> +/* Match table for of_platform binding */
>> +static const struct of_device_id keystone_qmss_of_match[] = {
>> + {
>> + .compatible = "ti,keystone-navigator-qmss",
>
> .data = (void *)QMSS,
>
>> + },
>> + {
>> + .compatible = "ti,keystone-navigator-qmss-l",
>> + .data = (void *)QMSS_LITE,
>> + },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, keystone_qmss_of_match);
>> +
>> static int knav_queue_probe(struct platform_device *pdev)
>> {
>> struct device_node *node = pdev->dev.of_node;
>> struct device_node *qmgrs, *queue_pools, *regions, *pdsps;
>> + const struct of_device_id *match;
>> struct device *dev = &pdev->dev;
>> u32 temp[2];
>> int ret;
>> @@ -1700,6 +1749,10 @@ static int knav_queue_probe(struct platform_device *pdev)
>> return -ENOMEM;
>> }
>>
>> + match = of_match_device(of_match_ptr(keystone_qmss_of_match), dev);
>> + if (match && match->data)
>> + kdev->version = QMSS_LITE;
>
> if (match)
> kdev->version = match->data;
> else
> error?
> [...]
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: net: renesas-ravb: Add support for r8a77470 SoC
From: Sergei Shtylyov @ 2018-03-29 14:51 UTC (permalink / raw)
To: Biju Das, David S . Miller, Rob Herring, Mark Rutland,
Russell King
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree, linux-renesas-soc, linux-arm-kernel,
netdev
In-Reply-To: <1522317775-35671-1-git-send-email-biju.das@bp.renesas.com>
Hello!
On 03/29/2018 01:02 PM, Biju Das wrote:
> Add a new compatible string for the RZ/G1C (R8A77470) SoC.
Needed solely to please checkpatch.pl. :-)
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Alexandre Belloni @ 2018-03-29 14:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180329144041.GA25752@lunn.ch>
On 29/03/2018 at 16:40:41 +0200, Andrew Lunn wrote:
> > > > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > > > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > > > + bus->phy_mask |= BIT(i);
> > > > + }
> > >
> > > Why do this? Especially so for the external bus, where the PHYs might
> > > have a GPIO reset line, and won't respond until the gpio is
> > > released. The core code does that just before it scans the bus, or
> > > just before it scans the particular address on the bus, depending on
> > > the scope of the GPIO.
> > >
> >
> > IIRC, this was needed when probing the bus without DT, in that case, the
> > mdiobus_scan loop of __mdiobus_register() will fail when doing the
> > get_phy_id for phys 0 to 31 because get_phy_id() transforms any error in
> > -EIO and so it is impossible to register the bus. Other drivers have a
> > similar code to handle that case.
>
> Hi Alexandre
>
> Do you mean mscc_miim_read() will return -EIO if there is no device on
> the bus at the address trying to be read? Most devices just return
> 0xffff because there is a pull up on the data line, nothing is driving
> it, so all 1's are read.
>
It will return -EIO but I tried to be clever and return -ENODEV but this
gets changed to -EIO by get_phy_id.
> It sounds like the correct fix is for get_phy_id() to look at the
> error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and
> maybe ENODEV, set *phy_id to 0xffffffff and return. The scan code
> should then do the correct thing.
>
That could work indeed. Do you want me to test and send a patch?
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 000/109] remove in-kernel calls to syscalls
From: Dominik Brodowski @ 2018-03-29 14:55 UTC (permalink / raw)
To: David Laight
Cc: Matthew Wilcox, linux-kernel@vger.kernel.org,
viro@ZenIV.linux.org.uk, torvalds@linux-foundation.org,
arnd@arndb.de, linux-arch@vger.kernel.org, hmclauchlan@fb.com,
tautschn@amazon.co.uk, Amir Goldstein, Andi Kleen, Andrew Morton,
Christoph Hellwig, Darren Hart, David S . Miller,
Eric W . Biederman, H . Peter Anvin, Ingo Molnar,
Jaswinder Singh <jaswi
In-Reply-To: <07438b1e94ff42a184adb7134a680069@AcuMS.aculab.com>
On Thu, Mar 29, 2018 at 02:46:44PM +0000, David Laight wrote:
> From: Dominik Brodowski
> > Sent: 29 March 2018 15:42
> > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > > > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > > > onwards to not call system call functions in the kernel: It is better to
> > > > use use a different calling convention for system calls there, where
> > > > struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands
> > > > processing over to the actual syscall function. This means that only those
> > > > parameters which are actually needed for a specific syscall are passed on
> > > > during syscall entry, instead of filling in six CPU registers with random
> > > > user space content all the time (which may cause serious trouble down the
> > > > call chain).[*]
> > >
> > > How do we stop new ones from springing up? Some kind of linker trick
> > > like was used to, er, "dissuade" people from using gets()?
> >
> > Once the patches which modify the syscall calling convention are merged,
> > it won't compile on 64-bit x86, but bark loudly. That should frighten anyone.
> > Meow.
>
> Should be pretty easy to ensure the prototypes aren't in any normal header.
That's exactly why the compile will fail.
> Renaming the global symbols (to not match the function name) will make it
> much harder to call them as well.
That still depends on the exact design of the patchset, which is still under
review.
Thanks,
Dominik
^ permalink raw reply
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Andrew Lunn @ 2018-03-29 14:57 UTC (permalink / raw)
To: Alexandre Belloni
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180329145352.GD12066@piout.net>
> > It sounds like the correct fix is for get_phy_id() to look at the
> > error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and
> > maybe ENODEV, set *phy_id to 0xffffffff and return. The scan code
> > should then do the correct thing.
> >
>
> That could work indeed. Do you want me to test and send a patch?
Yes please.
Thanks
Andrew
^ permalink raw reply
* Re: [net-next,v2,01/10] soc: ti: K2G: enhancement to support QMSS in NSS
From: Murali Karicheri @ 2018-03-29 14:59 UTC (permalink / raw)
To: Grygorii Strashko, robh+dt, ssantosh, malat, w-kwok2, devicetree,
linux-kernel, linux-arm-kernel, davem, netdev
Cc: mark.rutland
In-Reply-To: <1ccf03e7-17b4-cf00-176d-0e41038c88f8@ti.com>
On 03/28/2018 03:01 PM, Grygorii Strashko wrote:
> Hi Murali,
>
>>
>> +enum qmss_version {
>> + QMSS,
>> + QMSS_LITE,
>
> QMSS_66AK2G
>
OK.
>> +};
>> +
>> struct knav_device {
>> struct device *dev;
>> unsigned base_id;
>> @@ -305,6 +310,7 @@ struct knav_device {
>> struct list_head pools;
>> struct list_head pdsps;
>> struct list_head qmgrs;
>> + enum qmss_version version;
>> };
>>
>
> [...]
>
>> }
>>
>> +/* Match table for of_platform binding */
>> +static const struct of_device_id keystone_qmss_of_match[] = {
>> + {
>> + .compatible = "ti,keystone-navigator-qmss",
>
> .data = (void *)QMSS,
This seems to be unnecessary as QMSS is actually defined as zero. Also
this static. So that value is zero already in memory.
>
>> + },
>> + {
>> + .compatible = "ti,keystone-navigator-qmss-l",
>> + .data = (void *)QMSS_LITE,
>> + },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, keystone_qmss_of_match);
>> +
>> static int knav_queue_probe(struct platform_device *pdev)
>> {
>> struct device_node *node = pdev->dev.of_node;
>> struct device_node *qmgrs, *queue_pools, *regions, *pdsps;
>> + const struct of_device_id *match;
>> struct device *dev = &pdev->dev;
>> u32 temp[2];
>> int ret;
>> @@ -1700,6 +1749,10 @@ static int knav_queue_probe(struct platform_device *pdev)
>> return -ENOMEM;
>> }
>>
>> + match = of_match_device(of_match_ptr(keystone_qmss_of_match), dev);
>> + if (match && match->data)
>> + kdev->version = QMSS_LITE;
>
> if (match)
> kdev->version = match->data;
> else
> error?
Similar to above. This private memory is allocated using kzalloc which initializes
everything to zero. So the else part is unnecessary.
Murali
> [...]
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Fw: [Bug 199243] New: Ethernet doesn't work after sleep
From: Stephen Hemminger @ 2018-03-29 15:12 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Thu, 29 Mar 2018 15:02:07 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 199243] New: Ethernet doesn't work after sleep
https://bugzilla.kernel.org/show_bug.cgi?id=199243
Bug ID: 199243
Summary: Ethernet doesn't work after sleep
Product: Networking
Version: 2.5
Kernel Version: 4.15.12
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: zamazan4ik@tut.by
Regression: No
Description of problem:
Laptop with Fedora 27 cannot connect via Ethernet to a network after sleep (not
hibernation).
Version-Release number of selected component (if applicable):
Fedora 27
How reproducible:
Always
Steps to Reproduce:
1. With connected or disconnected Ethernet cable (in my case doesn't matter)
turn on sleep mode on a laptop.
2. Turn off sleep mode.
3. Ooops: Ethernet doesn't work (and even isn't detected).
Actual results:
There is chance to get workable Ethernet connection after sleep.
Expected results:
Fedora should be able to establish Ethernet connection after sleep.
Additional info:
Laptop model: Asus K55VJ-SX012D
Fedora 27
KDE Plasma 5.11.5
KDE Frameworks 5.43.0
Qt: 5.9.4
lspci | grep Ethernet: 04:00.2 Ethernet controller: Realtek Semiconductor Co.,
Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a)
uname -r: 4.15.12-301.fc27.x86_64
On Windows 10 all works fine. Ethernet cable is fine (tested on Windows and on
another machine).
Similar link to Redhat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1550701
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2018-03-29
From: David Miller @ 2018-03-29 15:23 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20180329072549.2880-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 29 Mar 2018 09:25:45 +0200
> 1) Remove a redundant pointer initialization esp_input_set_header().
> From Colin Ian King.
>
> 2) Mark the xfrm kmem_caches as __ro_after_init.
> From Alexey Dobriyan.
>
> 3) Do the checksum for an ipsec offlad packet in software
> if the device does not advertise NETIF_F_HW_ESP_TX_CSUM.
> From Shannon Nelson.
>
> 4) Use booleans for true and false instead of integers
> in xfrm_policy_cache_flush().
> From Gustavo A. R. Silva
>
> Please pull or let me know if there are problems.
Also pulled, thank you.
^ permalink raw reply
* Re: [RFC PATCH v2 00/14] Introducing AF_XDP support
From: Jesper Dangaard Brouer @ 2018-03-29 15:36 UTC (permalink / raw)
To: Björn Töpel
Cc: Eric Leblond, Karlsson, Magnus, Duyck, Alexander H,
Alexander Duyck, John Fastabend, Alexei Starovoitov,
Willem de Bruijn, Daniel Borkmann, Netdev, Björn Töpel,
michael.lundkvist, Brandeburg, Jesse, Singhai, Anjali,
Zhang, Qi Z, ravineet.singh, brouer
In-Reply-To: <CAJ+HfNi+WX-0Q_zQLnvRhJGvWSDaFXzi2EBPVA6c6Znh=cRC=g@mail.gmail.com>
On Thu, 29 Mar 2018 08:16:23 +0200 Björn Töpel <bjorn.topel@gmail.com> wrote:
> 2018-03-28 23:18 GMT+02:00 Eric Leblond <eric@regit.org>:
> > Hello,
> >
> > On Tue, 2018-03-27 at 18:59 +0200, Björn Töpel wrote:
> >> From: Björn Töpel <bjorn.topel@intel.com>
> >>
> >>
> > optimized for high performance packet processing and, in upcoming
> >> patch sets, zero-copy semantics. In this v2 version, we have removed
> >> all zero-copy related code in order to make it smaller, simpler and
> >> hopefully more review friendly. This RFC only supports copy-mode for
> >> the generic XDP path (XDP_SKB) for both RX and TX and copy-mode for
> >> RX
> >>
> >
> > ...
> >>
> >> How is then packets distributed between these two XSK? We have
> >> introduced a new BPF map called XSKMAP (or BPF_MAP_TYPE_XSKMAP in
> >> full). The user-space application can place an XSK at an arbitrary
> >> place in this map. The XDP program can then redirect a packet to a
> >> specific index in this map and at this point XDP validates that the
> >> XSK in that map was indeed bound to that device and queue number. If
> >> not, the packet is dropped. If the map is empty at that index, the
> >> packet is also dropped. This also means that it is currently
> >> mandatory
> >> to have an XDP program loaded (and one XSK in the XSKMAP) to be able
> >> to get any traffic to user space through the XSK.
> >
> > If I get it correctly, this feature will have to be used to bound
> > multiple sockets to a single queue and the eBPF filter will be
> > responsible of the load balancing. Am I correct ?
> >
>
> Exactly! The XDP program executing for a certain Rx queue will
> distribute the packets to the socket(s) in the xskmap.
It is important to understand that we (want/need to) maintain a Single
Producer Single Consumer (SPSC) scenario here, for performance reasons.
This _is_ maintained in this patchset AFAIK. But as the API user, you
have to understand that the responsibility of aligning this is yours!
If you don't the frames are dropped (silently).
The BPF programmer MUST select the correct XSKMAP index, such that
the ctx->rx_queue_index match the queue_id registered in the xdp_sock
(and bounded ifindex also match).
Bjørn, Magnus and I have discussed other API options. E.g. where the
XSKMAP index _is_ the rx_queue_index, and BPF programmer is not allowed
select another index. We settled on the API in the patchset, where BPF
programmer get more freedom, and can select an invalid index, that
cause packets to be dropped.
An advantage of this API is that we allow one RX-queue, to multiplex
into many xdk_sock's (all bound to this same RX-queue and ifindex).
This still maintain a Single Producer, as the RX-queue just have a
Single Producer relationship's with each xdp_sock.
I imagine, that Suricata/Eric, want to capture all the RX-queues on
the net_device. For this to happen, he need to create a xdp_sock per
RX-queue, and have a side-bpf-map that assist in the XSKMAP lookup, or
simply populate the XSKMAP to correspond to the rx_queue_index.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] lan78xx: Crash in lan78xx_writ_reg (Workqueue: events lan78xx_deferred_multicast_write)
From: David Miller @ 2018-03-29 15:36 UTC (permalink / raw)
To: raghuramchary.jallipalli; +Cc: netdev, unglinuxdriver, woojung.huh
In-Reply-To: <20180327092116.8867-1-raghuramchary.jallipalli@microchip.com>
From: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Date: Tue, 27 Mar 2018 14:51:16 +0530
> Description:
> Crash was reported with syzkaller pointing to lan78xx_write_reg routine.
>
> Root-cause:
> Proper cleanup of workqueues and init/setup routines was not happening
> in failure conditions.
>
> Fix:
> Handled the error conditions by cleaning up the queues and init/setup
> routines.
>
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* [PATCH] cw1200: fix spelling mistake: "Mailformed" -> "Malformed"
From: Colin King @ 2018-03-29 15:38 UTC (permalink / raw)
To: Solomon Peachy, Kalle Valo, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in wiphy_warn warning message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/st/cw1200/txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/st/cw1200/txrx.c b/drivers/net/wireless/st/cw1200/txrx.c
index e9050b41157a..f7b1b0062db3 100644
--- a/drivers/net/wireless/st/cw1200/txrx.c
+++ b/drivers/net/wireless/st/cw1200/txrx.c
@@ -1069,7 +1069,7 @@ void cw1200_rx_cb(struct cw1200_common *priv,
}
if (skb->len < sizeof(struct ieee80211_pspoll)) {
- wiphy_warn(priv->hw->wiphy, "Mailformed SDU rx'ed. Size is lesser than IEEE header.\n");
+ wiphy_warn(priv->hw->wiphy, "Malformed SDU rx'ed. Size is lesser than IEEE header.\n");
goto drop;
}
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek
From: Herbert Xu @ 2018-03-29 15:41 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: cluster-devel, netdev, LKML, NeilBrown, Thomas Graf, Tom Herbert
In-Reply-To: <CAHc6FU4i5LDoqXXTgAKtTA8EtGyawxXtY4iavo7NjHCsbX1G8w@mail.gmail.com>
On Thu, Mar 29, 2018 at 03:15:54PM +0200, Andreas Gruenbacher wrote:
>
> For all I know, Neil's latest plan is to get rhashtable_walk_peek
> replaced and removed because it is unfixable. This patch removes the
> one and only user.
His latest patch makes rhashtable_walk_peek stable in the face of
removals.
https://patchwork.ozlabs.org/patch/892534/
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH iproute] arrange prefix parsing code after redundant patches
From: Stephen Hemminger @ 2018-03-29 15:44 UTC (permalink / raw)
To: Alexander Zubkov; +Cc: Luca Boccassi, netdev, Serhey Popovych
In-Reply-To: <1522195033-13293-1-git-send-email-green@msu.ru>
On Wed, 28 Mar 2018 01:57:13 +0200
Alexander Zubkov <green@msu.ru> wrote:
> A problem was reported with parsing of prefixes all/any/default.
> Commit 7696f1097f79be2ce5984a8a16103fd17391cac2 fixes the problem,
> but there were also other pathces applied:
> 00b31a6b2ecf73ee477f701098164600a2bfe227, which were intended to
> fix the same problem. And they became redundant now. This patch
> reverts changes introduced by those redundant patches.
>
> Signed-off-by: Alexander Zubkov <green@msu.ru>
Thanks applied to current master branch
^ permalink raw reply
* Re: [PATCH net] hv_netvsc: enable multicast if necessary
From: David Miller @ 2018-03-29 15:46 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20180327182848.25056-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 27 Mar 2018 11:28:48 -0700
> My recent change to netvsc drive in how receive flags are handled
> broke multicast. The Hyper-v/Azure virtual interface there is not a
> multicast filter list, filtering is only all or none. The driver must
> enable all multicast if any multicast address is present.
>
> Fixes: 009f766ca238 ("hv_netvsc: filter multicast/broadcast")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: net: Add bindings for National Instruments XGE netdev
From: David Miller @ 2018-03-29 15:51 UTC (permalink / raw)
To: mdf; +Cc: linux-kernel, devicetree, netdev, robh+dt, andrew, f.fainelli
In-Reply-To: <20180327214315.3224-1-mdf@kernel.org>
From: Moritz Fischer <mdf@kernel.org>
Date: Tue, 27 Mar 2018 14:43:14 -0700
> This adds bindings for the NI XGE 1G/10G network device.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH v6 2/2] net: ethernet: nixge: Add support for National Instruments XGE netdev
From: David Miller @ 2018-03-29 15:51 UTC (permalink / raw)
To: mdf; +Cc: linux-kernel, devicetree, netdev, robh+dt, andrew, f.fainelli
In-Reply-To: <20180327214315.3224-2-mdf@kernel.org>
From: Moritz Fischer <mdf@kernel.org>
Date: Tue, 27 Mar 2018 14:43:15 -0700
> Add support for the National Instruments XGE 1/10G network device.
>
> It uses the EEPROM on the board via NVMEM.
>
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
Applied.
^ permalink raw reply
* pull-request: ieee802154-next 2018-03-29
From: Stefan Schmidt @ 2018-03-29 15:51 UTC (permalink / raw)
To: davem; +Cc: linux-wpan, alex.aring, netdev
Hello Dave.
An update from ieee802154 for *net-next*
Colin fixed a unused variable in the new mcr20a driver.
Harry fixed an unitialised data read in the debugfs interface of the
ca8210 driver.
If there are any issues or you think these are to late for -rc1 (both can also
go into -rc2 as they are simple fixes) let me know.
regards
Stefan Schmidt
The following changes since commit 23e19fd4fb07eebf96909a86b8545bc4aa682e54:
Merge branch 'tcp_bbr-more-GSO-work' (2018-03-01 21:44:29 -0500)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git ieee802154-for-davem-2018-03-29
for you to fetch changes up to 86674a97f5055f4c7f406563408096e8cf9364ff:
ieee802154: ca8210: fix uninitialised data read (2018-03-29 16:51:26 +0200)
----------------------------------------------------------------
Colin Ian King (1):
ieee802154: remove unused variable 'val'
Harry Morris (1):
ieee802154: ca8210: fix uninitialised data read
drivers/net/ieee802154/ca8210.c | 14 +++++++++++---
drivers/net/ieee802154/mcr20a.c | 2 --
2 files changed, 11 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH v14 net-next 00/12] Chelsio Inline TLS
From: Atul Gupta @ 2018-03-29 15:57 UTC (permalink / raw)
To: davem, herbert
Cc: davejwatson, sd, sbrivio, linux-crypto, netdev, werner, leedom,
swise, indranil, ganeshgr, atul.gupta
Thanks everyone for reviewing the series.
Dave, this should apply clean on net-next tree and I think it is ready
to merge.
Series for Chelsio Inline TLS driver (chtls)
Use tls ULP infrastructure to register chtls as Inline TLS driver.
Chtls use TCP Sockets to Tx/Rx TLS records.
TCP sk_proto APIs are enhanced to offload TLS record.
T6 adapter provides the following features:
-TLS record offload, TLS header, encrypt, digest and transmit
-TLS record receive and decrypt
-TLS keys store
-TCP/IP engine
-TLS engine
-GCM crypto engine [support CBC also]
TLS provides security at the transport layer. It uses TCP to provide
reliable end-to-end transport of application data.
It relies on TCP for any retransmission.
TLS session comprises of three parts:
a. TCP/IP connection
b. TLS handshake
c. Record layer processing
TLS handshake state machine is executed in host (refer standard
implementation eg. OpenSSL). Setsockopt [SOL_TCP, TCP_ULP]
initialize TCP proto-ops for Chelsio inline tls support.
setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
Tx and Rx Keys are decided during handshake and programmed on
the chip after CCS is exchanged.
struct tls12_crypto_info_aes_gcm_128 crypto_info
setsockopt(sock, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info))
Finish is the first encrypted/decrypted message tx/rx inline.
On the Tx path TLS engine receive plain text from openssl, insert IV,
fetches the tx key, create cipher text records and generate MAC.
TLS header is added to cipher text and forward to TCP/IP engine for
transport layer processing and transmission on wire.
TX PATH:
Apps--openssl--chtls---TLS engine---encrypt/auth---TCP/IP engine---wire
On the Rx side, data received is PDU aligned at record boundaries.
TLS processes only the complete record. If rx key is programmed on
CCS receive, data is decrypted and plain text is posted to host.
RX PATH:
Wire--cipher-text--TCP/IP engine [PDU align]---TLS engine---
decrypt/auth---plain-text--chtls--openssl--application
v14: -Reverse christmas tree style for variable declarations for
various functions in chtls_hw.c, chtls_io.c [Stefano Brivio]
- replaced break with return in tcp_state_to_flowc_state
[Stefano Brivio]
- renamed tlstx_seq_number to tlstx_incr_seqnum [Stefano Brivio]
- use bool for corked, should_push and send_should_push
[Stefano Brivio]
- removed "Reviewed-by" tag for Stefano, Sabrina, Dave Watson
v13: handle clean ctx free for HW_RECORD in tls_sk_proto_close
-removed SOCK_INLINE [chtls.h], using csk_conn_inline instead
in send_abort_rpl,chtls_send_abort_rpl,chtls_sendmsg,chtls_sendpage
-removed sk_no_receive [chtls_io.c] replaced with sk_shutdown &
RCV_SHUTDOWN in chtls_pt_recvmsg, peekmsg and chtls_recvmsg
-cleaned chtls_expansion_size [Stefano Brivio]
- u8 conf:3 in tls_sw_context to add TLS_HW_RECORD
-removed is_tls_skb, using tls_skb_inline [Stefano Brivio]
-reverse christmas tree formatting in chtls_io.c, chtls_cm.c
[Stefano Brivio]
-fixed build warning reported by kbuild robot
-retained ctx conf enum in chtls_main vs earlier versions, tls_prots
not used in chtls.
-cleanup [removed syn_sent, base_prot, added synq] [Michael Werner]
- passing struct fw_wr_hdr * to ofldtxq_stop [Casey]
- rebased on top of the current net-next
v12: patch against net-next
-fixed build error [reported by Julia]
-replace set_queue with skb_set_queue_mapping [Sabrina]
-copyright year correction [chtls]
v11: formatting and cleanup, few function rename and error
handling [Stefano Brivio]
- ctx freed later for TLS_HW_RECORD
- split tx and rx in different patch
v10: fixed following based on the review comments of Sabrina Dubroca
-docs header added for struct tls_device [tls.h]
-changed TLS_FULL_HW to TLS_HW_RECORD
-similary using tls-hw-record instead of tls-inline for
ethtool feature config
-added more description to patch sets
-replaced kmalloc/vmalloc/kfree with kvzalloc/kvfree
-reordered the patch sequence
-formatted entire patch for func return values
v9: corrected __u8 and similar usage
-create_ctx to alloc tls_context
-tls_hw_prot before sk !establish check
v8: tls_main.c cleanup comment [Dave Watson]
v7: func name change, use sk->sk_prot where required
v6: modify prot only for FULL_HW
-corrected commit message for patch 11
v5: set TLS_FULL_HW for registered inline tls drivers
-set TLS_FULL_HW prot for offload connection else move
to TLS_SW_TX
-Case handled for interface with same IP [Dave Miller]
-Removed Specific IP and INADDR_ANY handling [v4]
v4: removed chtls ULP type, retained tls ULP
-registered chtls with net tls
-defined struct tls_device to register the Inline drivers
-ethtool interface tls-inline to enable Inline TLS for interface
-prot update to support inline TLS
v3: fixed the kbuild test issues
-made few funtions static
-initialized few variables
v2: fixed the following based on the review comments of Stephan Mueller,
Stefano Brivio and Hannes Frederic
-Added more details in cover letter
-Fixed indentation and formating issues
-Using aes instead of aes-generic
-memset key info after programing the key on chip
-reordered the patch sequence
Atul Gupta (12):
tls: support for Inline tls record
ethtool: enable Inline TLS in HW
cxgb4: Inline TLS FW Interface
cxgb4: LLD driver changes to support TLS
crypto: chcr - Inline TLS Key Macros
crypto: chtls - structure and macro for Inline TLS
crypto: chtls - Program the TLS session Key
crypto : chtls - CPL handler definition
crypto: chtls - Inline TLS record Tx
crypto: chtls - Inline TLS record Rx
crypto: chtls - Register chtls with net tls
crypto: chtls - Makefile Kconfig
drivers/crypto/chelsio/Kconfig | 11 +
drivers/crypto/chelsio/Makefile | 1 +
drivers/crypto/chelsio/chcr_algo.h | 42 +
drivers/crypto/chelsio/chcr_core.h | 55 +-
drivers/crypto/chelsio/chtls/Makefile | 4 +
drivers/crypto/chelsio/chtls/chtls.h | 483 +++++
drivers/crypto/chelsio/chtls/chtls_cm.c | 2145 +++++++++++++++++++++++
drivers/crypto/chelsio/chtls/chtls_cm.h | 203 +++
drivers/crypto/chelsio/chtls/chtls_hw.c | 412 +++++
drivers/crypto/chelsio/chtls/chtls_io.c | 1850 +++++++++++++++++++
drivers/crypto/chelsio/chtls/chtls_main.c | 578 ++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 32 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 7 +
drivers/net/ethernet/chelsio/cxgb4/sge.c | 107 +-
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 122 +-
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 2 +
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 165 +-
include/linux/netdev_features.h | 2 +
include/net/tls.h | 32 +-
net/core/ethtool.c | 1 +
net/ipv4/tcp_minisocks.c | 1 +
net/tls/tls_main.c | 114 +-
22 files changed, 6343 insertions(+), 26 deletions(-)
create mode 100644 drivers/crypto/chelsio/chtls/Makefile
create mode 100644 drivers/crypto/chelsio/chtls/chtls.h
create mode 100644 drivers/crypto/chelsio/chtls/chtls_cm.c
create mode 100644 drivers/crypto/chelsio/chtls/chtls_cm.h
create mode 100644 drivers/crypto/chelsio/chtls/chtls_hw.c
create mode 100644 drivers/crypto/chelsio/chtls/chtls_io.c
create mode 100644 drivers/crypto/chelsio/chtls/chtls_main.c
--
1.8.3.1
^ permalink raw reply
* [PATCH v14 net-next 01/12] tls: support for Inline tls record
From: Atul Gupta @ 2018-03-29 15:57 UTC (permalink / raw)
To: davem, herbert
Cc: davejwatson, sd, sbrivio, linux-crypto, netdev, werner, leedom,
swise, indranil, ganeshgr, atul.gupta
In-Reply-To: <1522339074-4681-1-git-send-email-atul.gupta@chelsio.com>
Facility to register Inline TLS drivers to net/tls. Setup
TLS_HW_RECORD prot to listen on offload device.
Cases handled
- Inline TLS device exists, setup prot for TLS_HW_RECORD
- Atleast one Inline TLS exists, sets TLS_HW_RECORD.
- If non-inline device establish connection, move to TLS_SW_TX
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
---
include/net/tls.h | 32 ++++++++++++++-
net/tls/tls_main.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 142 insertions(+), 4 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index 437a746..3da8e13 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -56,6 +56,32 @@
#define TLS_RECORD_TYPE_DATA 0x17
#define TLS_AAD_SPACE_SIZE 13
+#define TLS_DEVICE_NAME_MAX 32
+
+/*
+ * This structure defines the routines for Inline TLS driver.
+ * The following routines are optional and filled with a
+ * null pointer if not defined.
+ *
+ * @name: Its the name of registered Inline tls device
+ * @dev_list: Inline tls device list
+ * int (*feature)(struct tls_device *device);
+ * Called to return Inline TLS driver capability
+ *
+ * int (*hash)(struct tls_device *device, struct sock *sk);
+ * This function sets Inline driver for listen and program
+ * device specific functioanlity as required
+ *
+ * void (*unhash)(struct tls_device *device, struct sock *sk);
+ * This function cleans listen state set by Inline TLS driver
+ */
+struct tls_device {
+ char name[TLS_DEVICE_NAME_MAX];
+ struct list_head dev_list;
+ int (*feature)(struct tls_device *device);
+ int (*hash)(struct tls_device *device, struct sock *sk);
+ void (*unhash)(struct tls_device *device, struct sock *sk);
+};
struct tls_sw_context {
struct crypto_aead *aead_send;
@@ -114,7 +140,7 @@ struct tls_context {
void *priv_ctx;
- u8 conf:2;
+ u8 conf:3;
struct cipher_context tx;
struct cipher_context rx;
@@ -135,6 +161,8 @@ struct tls_context {
int (*getsockopt)(struct sock *sk, int level,
int optname, char __user *optval,
int __user *optlen);
+ int (*hash)(struct sock *sk);
+ void (*unhash)(struct sock *sk);
};
int wait_on_pending_writer(struct sock *sk, long *timeo);
@@ -283,5 +311,7 @@ static inline struct tls_offload_context *tls_offload_ctx(
int tls_proccess_cmsg(struct sock *sk, struct msghdr *msg,
unsigned char *record_type);
+void tls_register_device(struct tls_device *device);
+void tls_unregister_device(struct tls_device *device);
#endif /* _TLS_OFFLOAD_H */
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 6f5c114..0d37997 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -38,6 +38,7 @@
#include <linux/highmem.h>
#include <linux/netdevice.h>
#include <linux/sched/signal.h>
+#include <linux/inetdevice.h>
#include <net/tls.h>
@@ -56,11 +57,14 @@ enum {
TLS_SW_TX,
TLS_SW_RX,
TLS_SW_RXTX,
+ TLS_HW_RECORD,
TLS_NUM_CONFIG,
};
static struct proto *saved_tcpv6_prot;
static DEFINE_MUTEX(tcpv6_prot_mutex);
+static LIST_HEAD(device_list);
+static DEFINE_MUTEX(device_mutex);
static struct proto tls_prots[TLS_NUM_PROTS][TLS_NUM_CONFIG];
static struct proto_ops tls_sw_proto_ops;
@@ -241,8 +245,12 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
lock_sock(sk);
sk_proto_close = ctx->sk_proto_close;
+ if (ctx->conf == TLS_HW_RECORD)
+ goto skip_tx_cleanup;
+
if (ctx->conf == TLS_BASE) {
kfree(ctx);
+ ctx = NULL;
goto skip_tx_cleanup;
}
@@ -276,6 +284,11 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
skip_tx_cleanup:
release_sock(sk);
sk_proto_close(sk, timeout);
+ /* free ctx for TLS_HW_RECORD, used by tcp_set_state
+ * for sk->sk_prot->unhash [tls_hw_unhash]
+ */
+ if (ctx && ctx->conf == TLS_HW_RECORD)
+ kfree(ctx);
}
static int do_tls_getsockopt_tx(struct sock *sk, char __user *optval,
@@ -493,6 +506,79 @@ static int tls_setsockopt(struct sock *sk, int level, int optname,
return do_tls_setsockopt(sk, optname, optval, optlen);
}
+static struct tls_context *create_ctx(struct sock *sk)
+{
+ struct inet_connection_sock *icsk = inet_csk(sk);
+ struct tls_context *ctx;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return NULL;
+
+ icsk->icsk_ulp_data = ctx;
+ return ctx;
+}
+
+static int tls_hw_prot(struct sock *sk)
+{
+ struct tls_context *ctx;
+ struct tls_device *dev;
+ int rc = 0;
+
+ mutex_lock(&device_mutex);
+ list_for_each_entry(dev, &device_list, dev_list) {
+ if (dev->feature && dev->feature(dev)) {
+ ctx = create_ctx(sk);
+ if (!ctx)
+ goto out;
+
+ ctx->hash = sk->sk_prot->hash;
+ ctx->unhash = sk->sk_prot->unhash;
+ ctx->sk_proto_close = sk->sk_prot->close;
+ ctx->conf = TLS_HW_RECORD;
+ update_sk_prot(sk, ctx);
+ rc = 1;
+ break;
+ }
+ }
+out:
+ mutex_unlock(&device_mutex);
+ return rc;
+}
+
+static void tls_hw_unhash(struct sock *sk)
+{
+ struct tls_context *ctx = tls_get_ctx(sk);
+ struct tls_device *dev;
+
+ mutex_lock(&device_mutex);
+ list_for_each_entry(dev, &device_list, dev_list) {
+ if (dev->unhash)
+ dev->unhash(dev, sk);
+ }
+ mutex_unlock(&device_mutex);
+ ctx->unhash(sk);
+}
+
+static int tls_hw_hash(struct sock *sk)
+{
+ struct tls_context *ctx = tls_get_ctx(sk);
+ struct tls_device *dev;
+ int err;
+
+ err = ctx->hash(sk);
+ mutex_lock(&device_mutex);
+ list_for_each_entry(dev, &device_list, dev_list) {
+ if (dev->hash)
+ err |= dev->hash(dev, sk);
+ }
+ mutex_unlock(&device_mutex);
+
+ if (err)
+ tls_hw_unhash(sk);
+ return err;
+}
+
static void build_protos(struct proto *prot, struct proto *base)
{
prot[TLS_BASE] = *base;
@@ -511,15 +597,22 @@ static void build_protos(struct proto *prot, struct proto *base)
prot[TLS_SW_RXTX] = prot[TLS_SW_TX];
prot[TLS_SW_RXTX].recvmsg = tls_sw_recvmsg;
prot[TLS_SW_RXTX].close = tls_sk_proto_close;
+
+ prot[TLS_HW_RECORD] = *base;
+ prot[TLS_HW_RECORD].hash = tls_hw_hash;
+ prot[TLS_HW_RECORD].unhash = tls_hw_unhash;
+ prot[TLS_HW_RECORD].close = tls_sk_proto_close;
}
static int tls_init(struct sock *sk)
{
int ip_ver = sk->sk_family == AF_INET6 ? TLSV6 : TLSV4;
- struct inet_connection_sock *icsk = inet_csk(sk);
struct tls_context *ctx;
int rc = 0;
+ if (tls_hw_prot(sk))
+ goto out;
+
/* The TLS ulp is currently supported only for TCP sockets
* in ESTABLISHED state.
* Supporting sockets in LISTEN state will require us
@@ -530,12 +623,11 @@ static int tls_init(struct sock *sk)
return -ENOTSUPP;
/* allocate tls context */
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ ctx = create_ctx(sk);
if (!ctx) {
rc = -ENOMEM;
goto out;
}
- icsk->icsk_ulp_data = ctx;
ctx->setsockopt = sk->sk_prot->setsockopt;
ctx->getsockopt = sk->sk_prot->getsockopt;
ctx->sk_proto_close = sk->sk_prot->close;
@@ -557,6 +649,22 @@ static int tls_init(struct sock *sk)
return rc;
}
+void tls_register_device(struct tls_device *device)
+{
+ mutex_lock(&device_mutex);
+ list_add_tail(&device->dev_list, &device_list);
+ mutex_unlock(&device_mutex);
+}
+EXPORT_SYMBOL(tls_register_device);
+
+void tls_unregister_device(struct tls_device *device)
+{
+ mutex_lock(&device_mutex);
+ list_del(&device->dev_list);
+ mutex_unlock(&device_mutex);
+}
+EXPORT_SYMBOL(tls_unregister_device);
+
static struct tcp_ulp_ops tcp_tls_ulp_ops __read_mostly = {
.name = "tls",
.uid = TCP_ULP_TLS,
--
1.8.3.1
^ permalink raw reply related
* [PATCH v14 net-next 02/12] ethtool: enable Inline TLS in HW
From: Atul Gupta @ 2018-03-29 15:57 UTC (permalink / raw)
To: davem, herbert
Cc: davejwatson, sd, sbrivio, linux-crypto, netdev, werner, leedom,
swise, indranil, ganeshgr, atul.gupta
In-Reply-To: <1522339074-4681-1-git-send-email-atul.gupta@chelsio.com>
Ethtool option enables TLS record offload on HW, user
configures the feature for netdev capable of Inline TLS.
This allows user to define custom sk_prot for Inline TLS sock
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
---
include/linux/netdev_features.h | 2 ++
net/core/ethtool.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index db84c51..35b79f4 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -79,6 +79,7 @@ enum {
NETIF_F_RX_UDP_TUNNEL_PORT_BIT, /* Offload of RX port for UDP tunnels */
NETIF_F_GRO_HW_BIT, /* Hardware Generic receive offload */
+ NETIF_F_HW_TLS_RECORD_BIT, /* Offload TLS record */
/*
* Add your fresh new feature above and remember to update
@@ -145,6 +146,7 @@ enum {
#define NETIF_F_HW_ESP __NETIF_F(HW_ESP)
#define NETIF_F_HW_ESP_TX_CSUM __NETIF_F(HW_ESP_TX_CSUM)
#define NETIF_F_RX_UDP_TUNNEL_PORT __NETIF_F(RX_UDP_TUNNEL_PORT)
+#define NETIF_F_HW_TLS_RECORD __NETIF_F(HW_TLS_RECORD)
#define for_each_netdev_feature(mask_addr, bit) \
for_each_set_bit(bit, (unsigned long *)mask_addr, NETDEV_FEATURE_COUNT)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index bb6e498..eabd35a 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -107,6 +107,7 @@ int ethtool_op_get_ts_info(struct net_device *dev, struct ethtool_ts_info *info)
[NETIF_F_HW_ESP_BIT] = "esp-hw-offload",
[NETIF_F_HW_ESP_TX_CSUM_BIT] = "esp-tx-csum-hw-offload",
[NETIF_F_RX_UDP_TUNNEL_PORT_BIT] = "rx-udp_tunnel-port-offload",
+ [NETIF_F_HW_TLS_RECORD_BIT] = "tls-hw-record",
};
static const char
--
1.8.3.1
^ permalink raw reply related
* [PATCH v14 net-next 03/12] cxgb4: Inline TLS FW Interface
From: Atul Gupta @ 2018-03-29 15:57 UTC (permalink / raw)
To: davem, herbert
Cc: davejwatson, sd, sbrivio, linux-crypto, netdev, werner, leedom,
swise, indranil, ganeshgr, atul.gupta
In-Reply-To: <1522339074-4681-1-git-send-email-atul.gupta@chelsio.com>
Key area size in hw-config file. CPL struct for TLS request
and response. Work request for Inline TLS.
Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
Reviewed-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 122 ++++++++++++++++++-
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 2 +
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 165 +++++++++++++++++++++++++-
3 files changed, 283 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h b/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
index 5e8f5ca..fe2029e9 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
@@ -82,13 +82,15 @@ enum {
CPL_RX_ISCSI_CMP = 0x45,
CPL_TRACE_PKT_T5 = 0x48,
CPL_RX_ISCSI_DDP = 0x49,
+ CPL_RX_TLS_CMP = 0x4E,
CPL_RDMA_READ_REQ = 0x60,
CPL_PASS_OPEN_REQ6 = 0x81,
CPL_ACT_OPEN_REQ6 = 0x83,
- CPL_TX_TLS_PDU = 0x88,
+ CPL_TX_TLS_PDU = 0x88,
+ CPL_TX_TLS_SFO = 0x89,
CPL_TX_SEC_PDU = 0x8A,
CPL_TX_TLS_ACK = 0x8B,
@@ -98,6 +100,7 @@ enum {
CPL_RX_MPS_PKT = 0xAF,
CPL_TRACE_PKT = 0xB0,
+ CPL_TLS_DATA = 0xB1,
CPL_ISCSI_DATA = 0xB2,
CPL_FW4_MSG = 0xC0,
@@ -155,6 +158,7 @@ enum {
ULP_MODE_RDMA = 4,
ULP_MODE_TCPDDP = 5,
ULP_MODE_FCOE = 6,
+ ULP_MODE_TLS = 8,
};
enum {
@@ -1445,6 +1449,14 @@ struct cpl_tx_data {
#define T6_TX_FORCE_V(x) ((x) << T6_TX_FORCE_S)
#define T6_TX_FORCE_F T6_TX_FORCE_V(1U)
+#define TX_SHOVE_S 14
+#define TX_SHOVE_V(x) ((x) << TX_SHOVE_S)
+
+#define TX_ULP_MODE_S 10
+#define TX_ULP_MODE_M 0x7
+#define TX_ULP_MODE_V(x) ((x) << TX_ULP_MODE_S)
+#define TX_ULP_MODE_G(x) (((x) >> TX_ULP_MODE_S) & TX_ULP_MODE_M)
+
enum {
ULP_TX_MEM_READ = 2,
ULP_TX_MEM_WRITE = 3,
@@ -1455,12 +1467,21 @@ enum {
ULP_TX_SC_NOOP = 0x80,
ULP_TX_SC_IMM = 0x81,
ULP_TX_SC_DSGL = 0x82,
- ULP_TX_SC_ISGL = 0x83
+ ULP_TX_SC_ISGL = 0x83,
+ ULP_TX_SC_MEMRD = 0x86
};
#define ULPTX_CMD_S 24
#define ULPTX_CMD_V(x) ((x) << ULPTX_CMD_S)
+#define ULPTX_LEN16_S 0
+#define ULPTX_LEN16_M 0xFF
+#define ULPTX_LEN16_V(x) ((x) << ULPTX_LEN16_S)
+
+#define ULP_TX_SC_MORE_S 23
+#define ULP_TX_SC_MORE_V(x) ((x) << ULP_TX_SC_MORE_S)
+#define ULP_TX_SC_MORE_F ULP_TX_SC_MORE_V(1U)
+
struct ulptx_sge_pair {
__be32 len[2];
__be64 addr[2];
@@ -2183,4 +2204,101 @@ struct cpl_srq_table_rpl {
#define SRQT_IDX_V(x) ((x) << SRQT_IDX_S)
#define SRQT_IDX_G(x) (((x) >> SRQT_IDX_S) & SRQT_IDX_M)
+struct cpl_tx_tls_sfo {
+ __be32 op_to_seg_len;
+ __be32 pld_len;
+ __be32 type_protover;
+ __be32 r1_lo;
+ __be32 seqno_numivs;
+ __be32 ivgen_hdrlen;
+ __be64 scmd1;
+};
+
+/* cpl_tx_tls_sfo macros */
+#define CPL_TX_TLS_SFO_OPCODE_S 24
+#define CPL_TX_TLS_SFO_OPCODE_V(x) ((x) << CPL_TX_TLS_SFO_OPCODE_S)
+
+#define CPL_TX_TLS_SFO_DATA_TYPE_S 20
+#define CPL_TX_TLS_SFO_DATA_TYPE_V(x) ((x) << CPL_TX_TLS_SFO_DATA_TYPE_S)
+
+#define CPL_TX_TLS_SFO_CPL_LEN_S 16
+#define CPL_TX_TLS_SFO_CPL_LEN_V(x) ((x) << CPL_TX_TLS_SFO_CPL_LEN_S)
+
+#define CPL_TX_TLS_SFO_SEG_LEN_S 0
+#define CPL_TX_TLS_SFO_SEG_LEN_M 0xffff
+#define CPL_TX_TLS_SFO_SEG_LEN_V(x) ((x) << CPL_TX_TLS_SFO_SEG_LEN_S)
+#define CPL_TX_TLS_SFO_SEG_LEN_G(x) \
+ (((x) >> CPL_TX_TLS_SFO_SEG_LEN_S) & CPL_TX_TLS_SFO_SEG_LEN_M)
+
+#define CPL_TX_TLS_SFO_TYPE_S 24
+#define CPL_TX_TLS_SFO_TYPE_M 0xff
+#define CPL_TX_TLS_SFO_TYPE_V(x) ((x) << CPL_TX_TLS_SFO_TYPE_S)
+#define CPL_TX_TLS_SFO_TYPE_G(x) \
+ (((x) >> CPL_TX_TLS_SFO_TYPE_S) & CPL_TX_TLS_SFO_TYPE_M)
+
+#define CPL_TX_TLS_SFO_PROTOVER_S 8
+#define CPL_TX_TLS_SFO_PROTOVER_M 0xffff
+#define CPL_TX_TLS_SFO_PROTOVER_V(x) ((x) << CPL_TX_TLS_SFO_PROTOVER_S)
+#define CPL_TX_TLS_SFO_PROTOVER_G(x) \
+ (((x) >> CPL_TX_TLS_SFO_PROTOVER_S) & CPL_TX_TLS_SFO_PROTOVER_M)
+
+struct cpl_tls_data {
+ struct rss_header rsshdr;
+ union opcode_tid ot;
+ __be32 length_pkd;
+ __be32 seq;
+ __be32 r1;
+};
+
+#define CPL_TLS_DATA_OPCODE_S 24
+#define CPL_TLS_DATA_OPCODE_M 0xff
+#define CPL_TLS_DATA_OPCODE_V(x) ((x) << CPL_TLS_DATA_OPCODE_S)
+#define CPL_TLS_DATA_OPCODE_G(x) \
+ (((x) >> CPL_TLS_DATA_OPCODE_S) & CPL_TLS_DATA_OPCODE_M)
+
+#define CPL_TLS_DATA_TID_S 0
+#define CPL_TLS_DATA_TID_M 0xffffff
+#define CPL_TLS_DATA_TID_V(x) ((x) << CPL_TLS_DATA_TID_S)
+#define CPL_TLS_DATA_TID_G(x) \
+ (((x) >> CPL_TLS_DATA_TID_S) & CPL_TLS_DATA_TID_M)
+
+#define CPL_TLS_DATA_LENGTH_S 0
+#define CPL_TLS_DATA_LENGTH_M 0xffff
+#define CPL_TLS_DATA_LENGTH_V(x) ((x) << CPL_TLS_DATA_LENGTH_S)
+#define CPL_TLS_DATA_LENGTH_G(x) \
+ (((x) >> CPL_TLS_DATA_LENGTH_S) & CPL_TLS_DATA_LENGTH_M)
+
+struct cpl_rx_tls_cmp {
+ struct rss_header rsshdr;
+ union opcode_tid ot;
+ __be32 pdulength_length;
+ __be32 seq;
+ __be32 ddp_report;
+ __be32 r;
+ __be32 ddp_valid;
+};
+
+#define CPL_RX_TLS_CMP_OPCODE_S 24
+#define CPL_RX_TLS_CMP_OPCODE_M 0xff
+#define CPL_RX_TLS_CMP_OPCODE_V(x) ((x) << CPL_RX_TLS_CMP_OPCODE_S)
+#define CPL_RX_TLS_CMP_OPCODE_G(x) \
+ (((x) >> CPL_RX_TLS_CMP_OPCODE_S) & CPL_RX_TLS_CMP_OPCODE_M)
+
+#define CPL_RX_TLS_CMP_TID_S 0
+#define CPL_RX_TLS_CMP_TID_M 0xffffff
+#define CPL_RX_TLS_CMP_TID_V(x) ((x) << CPL_RX_TLS_CMP_TID_S)
+#define CPL_RX_TLS_CMP_TID_G(x) \
+ (((x) >> CPL_RX_TLS_CMP_TID_S) & CPL_RX_TLS_CMP_TID_M)
+
+#define CPL_RX_TLS_CMP_PDULENGTH_S 16
+#define CPL_RX_TLS_CMP_PDULENGTH_M 0xffff
+#define CPL_RX_TLS_CMP_PDULENGTH_V(x) ((x) << CPL_RX_TLS_CMP_PDULENGTH_S)
+#define CPL_RX_TLS_CMP_PDULENGTH_G(x) \
+ (((x) >> CPL_RX_TLS_CMP_PDULENGTH_S) & CPL_RX_TLS_CMP_PDULENGTH_M)
+
+#define CPL_RX_TLS_CMP_LENGTH_S 0
+#define CPL_RX_TLS_CMP_LENGTH_M 0xffff
+#define CPL_RX_TLS_CMP_LENGTH_V(x) ((x) << CPL_RX_TLS_CMP_LENGTH_S)
+#define CPL_RX_TLS_CMP_LENGTH_G(x) \
+ (((x) >> CPL_RX_TLS_CMP_LENGTH_S) & CPL_RX_TLS_CMP_LENGTH_M)
#endif /* __T4_MSG_H */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
index a6df733..276fdf2 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
@@ -2775,6 +2775,8 @@
#define ULP_RX_LA_RDPTR_A 0x19240
#define ULP_RX_LA_RDDATA_A 0x19244
#define ULP_RX_LA_WRPTR_A 0x19248
+#define ULP_RX_TLS_KEY_LLIMIT_A 0x192ac
+#define ULP_RX_TLS_KEY_ULIMIT_A 0x192b0
#define HPZ3_S 24
#define HPZ3_V(x) ((x) << HPZ3_S)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 544757f..e3d4751 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -105,6 +105,7 @@ enum fw_wr_opcodes {
FW_RI_INV_LSTAG_WR = 0x1a,
FW_ISCSI_TX_DATA_WR = 0x45,
FW_PTP_TX_PKT_WR = 0x46,
+ FW_TLSTX_DATA_WR = 0x68,
FW_CRYPTO_LOOKASIDE_WR = 0X6d,
FW_LASTC2E_WR = 0x70,
FW_FILTER2_WR = 0x77
@@ -635,6 +636,30 @@ struct fw_ofld_connection_wr {
#define FW_OFLD_CONNECTION_WR_CPLPASSACCEPTRPL_F \
FW_OFLD_CONNECTION_WR_CPLPASSACCEPTRPL_V(1U)
+enum fw_flowc_mnem_tcpstate {
+ FW_FLOWC_MNEM_TCPSTATE_CLOSED = 0, /* illegal */
+ FW_FLOWC_MNEM_TCPSTATE_LISTEN = 1, /* illegal */
+ FW_FLOWC_MNEM_TCPSTATE_SYNSENT = 2, /* illegal */
+ FW_FLOWC_MNEM_TCPSTATE_SYNRECEIVED = 3, /* illegal */
+ FW_FLOWC_MNEM_TCPSTATE_ESTABLISHED = 4, /* default */
+ FW_FLOWC_MNEM_TCPSTATE_CLOSEWAIT = 5, /* got peer close already */
+ FW_FLOWC_MNEM_TCPSTATE_FINWAIT1 = 6, /* haven't gotten ACK for FIN and
+ * will resend FIN - equiv ESTAB
+ */
+ FW_FLOWC_MNEM_TCPSTATE_CLOSING = 7, /* haven't gotten ACK for FIN and
+ * will resend FIN but have
+ * received FIN
+ */
+ FW_FLOWC_MNEM_TCPSTATE_LASTACK = 8, /* haven't gotten ACK for FIN and
+ * will resend FIN but have
+ * received FIN
+ */
+ FW_FLOWC_MNEM_TCPSTATE_FINWAIT2 = 9, /* sent FIN and got FIN + ACK,
+ * waiting for FIN
+ */
+ FW_FLOWC_MNEM_TCPSTATE_TIMEWAIT = 10, /* not expected */
+};
+
enum fw_flowc_mnem {
FW_FLOWC_MNEM_PFNVFN, /* PFN [15:8] VFN [7:0] */
FW_FLOWC_MNEM_CH,
@@ -651,6 +676,8 @@ enum fw_flowc_mnem {
FW_FLOWC_MNEM_DCBPRIO,
FW_FLOWC_MNEM_SND_SCALE,
FW_FLOWC_MNEM_RCV_SCALE,
+ FW_FLOWC_MNEM_ULD_MODE,
+ FW_FLOWC_MNEM_MAX,
};
struct fw_flowc_mnemval {
@@ -675,6 +702,14 @@ struct fw_ofld_tx_data_wr {
__be32 tunnel_to_proxy;
};
+#define FW_OFLD_TX_DATA_WR_ALIGNPLD_S 30
+#define FW_OFLD_TX_DATA_WR_ALIGNPLD_V(x) ((x) << FW_OFLD_TX_DATA_WR_ALIGNPLD_S)
+#define FW_OFLD_TX_DATA_WR_ALIGNPLD_F FW_OFLD_TX_DATA_WR_ALIGNPLD_V(1U)
+
+#define FW_OFLD_TX_DATA_WR_SHOVE_S 29
+#define FW_OFLD_TX_DATA_WR_SHOVE_V(x) ((x) << FW_OFLD_TX_DATA_WR_SHOVE_S)
+#define FW_OFLD_TX_DATA_WR_SHOVE_F FW_OFLD_TX_DATA_WR_SHOVE_V(1U)
+
#define FW_OFLD_TX_DATA_WR_TUNNEL_S 19
#define FW_OFLD_TX_DATA_WR_TUNNEL_V(x) ((x) << FW_OFLD_TX_DATA_WR_TUNNEL_S)
@@ -691,10 +726,6 @@ struct fw_ofld_tx_data_wr {
#define FW_OFLD_TX_DATA_WR_MORE_S 15
#define FW_OFLD_TX_DATA_WR_MORE_V(x) ((x) << FW_OFLD_TX_DATA_WR_MORE_S)
-#define FW_OFLD_TX_DATA_WR_SHOVE_S 14
-#define FW_OFLD_TX_DATA_WR_SHOVE_V(x) ((x) << FW_OFLD_TX_DATA_WR_SHOVE_S)
-#define FW_OFLD_TX_DATA_WR_SHOVE_F FW_OFLD_TX_DATA_WR_SHOVE_V(1U)
-
#define FW_OFLD_TX_DATA_WR_ULPMODE_S 10
#define FW_OFLD_TX_DATA_WR_ULPMODE_V(x) ((x) << FW_OFLD_TX_DATA_WR_ULPMODE_S)
@@ -1121,6 +1152,12 @@ enum fw_caps_config_iscsi {
FW_CAPS_CONFIG_ISCSI_TARGET_CNXOFLD = 0x00000008,
};
+enum fw_caps_config_crypto {
+ FW_CAPS_CONFIG_CRYPTO_LOOKASIDE = 0x00000001,
+ FW_CAPS_CONFIG_TLS_INLINE = 0x00000002,
+ FW_CAPS_CONFIG_IPSEC_INLINE = 0x00000004,
+};
+
enum fw_caps_config_fcoe {
FW_CAPS_CONFIG_FCOE_INITIATOR = 0x00000001,
FW_CAPS_CONFIG_FCOE_TARGET = 0x00000002,
@@ -1266,6 +1303,8 @@ enum fw_params_param_pfvf {
FW_PARAMS_PARAM_PFVF_CPLFW4MSG_ENCAP = 0x31,
FW_PARAMS_PARAM_PFVF_HPFILTER_START = 0x32,
FW_PARAMS_PARAM_PFVF_HPFILTER_END = 0x33,
+ FW_PARAMS_PARAM_PFVF_TLS_START = 0x34,
+ FW_PARAMS_PARAM_PFVF_TLS_END = 0x35,
FW_PARAMS_PARAM_PFVF_NCRYPTO_LOOKASIDE = 0x39,
FW_PARAMS_PARAM_PFVF_PORT_CAPS32 = 0x3A,
};
@@ -3839,4 +3878,122 @@ struct fw_crypto_lookaside_wr {
(((x) >> FW_CRYPTO_LOOKASIDE_WR_HASH_SIZE_S) & \
FW_CRYPTO_LOOKASIDE_WR_HASH_SIZE_M)
+struct fw_tlstx_data_wr {
+ __be32 op_to_immdlen;
+ __be32 flowid_len16;
+ __be32 plen;
+ __be32 lsodisable_to_flags;
+ __be32 r5;
+ __be32 ctxloc_to_exp;
+ __be16 mfs;
+ __be16 adjustedplen_pkd;
+ __be16 expinplenmax_pkd;
+ u8 pdusinplenmax_pkd;
+ u8 r10;
+};
+
+#define FW_TLSTX_DATA_WR_OPCODE_S 24
+#define FW_TLSTX_DATA_WR_OPCODE_M 0xff
+#define FW_TLSTX_DATA_WR_OPCODE_V(x) ((x) << FW_TLSTX_DATA_WR_OPCODE_S)
+#define FW_TLSTX_DATA_WR_OPCODE_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_OPCODE_S) & FW_TLSTX_DATA_WR_OPCODE_M)
+
+#define FW_TLSTX_DATA_WR_COMPL_S 21
+#define FW_TLSTX_DATA_WR_COMPL_M 0x1
+#define FW_TLSTX_DATA_WR_COMPL_V(x) ((x) << FW_TLSTX_DATA_WR_COMPL_S)
+#define FW_TLSTX_DATA_WR_COMPL_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_COMPL_S) & FW_TLSTX_DATA_WR_COMPL_M)
+#define FW_TLSTX_DATA_WR_COMPL_F FW_TLSTX_DATA_WR_COMPL_V(1U)
+
+#define FW_TLSTX_DATA_WR_IMMDLEN_S 0
+#define FW_TLSTX_DATA_WR_IMMDLEN_M 0xff
+#define FW_TLSTX_DATA_WR_IMMDLEN_V(x) ((x) << FW_TLSTX_DATA_WR_IMMDLEN_S)
+#define FW_TLSTX_DATA_WR_IMMDLEN_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_IMMDLEN_S) & FW_TLSTX_DATA_WR_IMMDLEN_M)
+
+#define FW_TLSTX_DATA_WR_FLOWID_S 8
+#define FW_TLSTX_DATA_WR_FLOWID_M 0xfffff
+#define FW_TLSTX_DATA_WR_FLOWID_V(x) ((x) << FW_TLSTX_DATA_WR_FLOWID_S)
+#define FW_TLSTX_DATA_WR_FLOWID_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_FLOWID_S) & FW_TLSTX_DATA_WR_FLOWID_M)
+
+#define FW_TLSTX_DATA_WR_LEN16_S 0
+#define FW_TLSTX_DATA_WR_LEN16_M 0xff
+#define FW_TLSTX_DATA_WR_LEN16_V(x) ((x) << FW_TLSTX_DATA_WR_LEN16_S)
+#define FW_TLSTX_DATA_WR_LEN16_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_LEN16_S) & FW_TLSTX_DATA_WR_LEN16_M)
+
+#define FW_TLSTX_DATA_WR_LSODISABLE_S 31
+#define FW_TLSTX_DATA_WR_LSODISABLE_M 0x1
+#define FW_TLSTX_DATA_WR_LSODISABLE_V(x) \
+ ((x) << FW_TLSTX_DATA_WR_LSODISABLE_S)
+#define FW_TLSTX_DATA_WR_LSODISABLE_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_LSODISABLE_S) & FW_TLSTX_DATA_WR_LSODISABLE_M)
+#define FW_TLSTX_DATA_WR_LSODISABLE_F FW_TLSTX_DATA_WR_LSODISABLE_V(1U)
+
+#define FW_TLSTX_DATA_WR_ALIGNPLD_S 30
+#define FW_TLSTX_DATA_WR_ALIGNPLD_M 0x1
+#define FW_TLSTX_DATA_WR_ALIGNPLD_V(x) ((x) << FW_TLSTX_DATA_WR_ALIGNPLD_S)
+#define FW_TLSTX_DATA_WR_ALIGNPLD_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_ALIGNPLD_S) & FW_TLSTX_DATA_WR_ALIGNPLD_M)
+#define FW_TLSTX_DATA_WR_ALIGNPLD_F FW_TLSTX_DATA_WR_ALIGNPLD_V(1U)
+
+#define FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_S 29
+#define FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_M 0x1
+#define FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_V(x) \
+ ((x) << FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_S)
+#define FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_S) & \
+ FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_M)
+#define FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_F FW_TLSTX_DATA_WR_ALIGNPLDSHOVE_V(1U)
+
+#define FW_TLSTX_DATA_WR_FLAGS_S 0
+#define FW_TLSTX_DATA_WR_FLAGS_M 0xfffffff
+#define FW_TLSTX_DATA_WR_FLAGS_V(x) ((x) << FW_TLSTX_DATA_WR_FLAGS_S)
+#define FW_TLSTX_DATA_WR_FLAGS_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_FLAGS_S) & FW_TLSTX_DATA_WR_FLAGS_M)
+
+#define FW_TLSTX_DATA_WR_CTXLOC_S 30
+#define FW_TLSTX_DATA_WR_CTXLOC_M 0x3
+#define FW_TLSTX_DATA_WR_CTXLOC_V(x) ((x) << FW_TLSTX_DATA_WR_CTXLOC_S)
+#define FW_TLSTX_DATA_WR_CTXLOC_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_CTXLOC_S) & FW_TLSTX_DATA_WR_CTXLOC_M)
+
+#define FW_TLSTX_DATA_WR_IVDSGL_S 29
+#define FW_TLSTX_DATA_WR_IVDSGL_M 0x1
+#define FW_TLSTX_DATA_WR_IVDSGL_V(x) ((x) << FW_TLSTX_DATA_WR_IVDSGL_S)
+#define FW_TLSTX_DATA_WR_IVDSGL_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_IVDSGL_S) & FW_TLSTX_DATA_WR_IVDSGL_M)
+#define FW_TLSTX_DATA_WR_IVDSGL_F FW_TLSTX_DATA_WR_IVDSGL_V(1U)
+
+#define FW_TLSTX_DATA_WR_KEYSIZE_S 24
+#define FW_TLSTX_DATA_WR_KEYSIZE_M 0x1f
+#define FW_TLSTX_DATA_WR_KEYSIZE_V(x) ((x) << FW_TLSTX_DATA_WR_KEYSIZE_S)
+#define FW_TLSTX_DATA_WR_KEYSIZE_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_KEYSIZE_S) & FW_TLSTX_DATA_WR_KEYSIZE_M)
+
+#define FW_TLSTX_DATA_WR_NUMIVS_S 14
+#define FW_TLSTX_DATA_WR_NUMIVS_M 0xff
+#define FW_TLSTX_DATA_WR_NUMIVS_V(x) ((x) << FW_TLSTX_DATA_WR_NUMIVS_S)
+#define FW_TLSTX_DATA_WR_NUMIVS_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_NUMIVS_S) & FW_TLSTX_DATA_WR_NUMIVS_M)
+
+#define FW_TLSTX_DATA_WR_EXP_S 0
+#define FW_TLSTX_DATA_WR_EXP_M 0x3fff
+#define FW_TLSTX_DATA_WR_EXP_V(x) ((x) << FW_TLSTX_DATA_WR_EXP_S)
+#define FW_TLSTX_DATA_WR_EXP_G(x) \
+ (((x) >> FW_TLSTX_DATA_WR_EXP_S) & FW_TLSTX_DATA_WR_EXP_M)
+
+#define FW_TLSTX_DATA_WR_ADJUSTEDPLEN_S 1
+#define FW_TLSTX_DATA_WR_ADJUSTEDPLEN_V(x) \
+ ((x) << FW_TLSTX_DATA_WR_ADJUSTEDPLEN_S)
+
+#define FW_TLSTX_DATA_WR_EXPINPLENMAX_S 4
+#define FW_TLSTX_DATA_WR_EXPINPLENMAX_V(x) \
+ ((x) << FW_TLSTX_DATA_WR_EXPINPLENMAX_S)
+
+#define FW_TLSTX_DATA_WR_PDUSINPLENMAX_S 2
+#define FW_TLSTX_DATA_WR_PDUSINPLENMAX_V(x) \
+ ((x) << FW_TLSTX_DATA_WR_PDUSINPLENMAX_S)
+
#endif /* _T4FW_INTERFACE_H_ */
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox