Re: [PATCH] arm64: dts: ensure backward compatibility of the AP807 Xenon

ic for other OSs/firmware that use > Linux device tree sources as a reference. Resolve the problem > with backward compatibility by restoring a previous compatible > string as secondary one. > > Signed-off-by: Marcin Wojtas Reviewed-by: Andrew Lunn Andrew

[PATCH] arm64: dts: ensure backward compatibility of the AP807 Xenon

the problem with backward compatibility by restoring a previous compatible string as secondary one. Signed-off-by: Marcin Wojtas --- arch/arm64/boot/dts/marvell/armada-ap807.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/marvell/armada-ap807.dtsi b

[for-next][PATCH 10/12] tracing: Add a backward-compatibility check for synthetic event creation

backward compatibility, the old synthetic event command +* format did not require semicolons, and in order to not +* break user space, that old format must still work. If a new +* feature is added, then the format that uses the new feature +* will be required to have

[PATCH 5.10 52/57] habanalabs: fix backward compatibility of idle check

From: Oded Gabbay [ Upstream commit f8abaf379bfe19600f96ae79a6759eb37039ae05 ] Need to take the lower 32 bits of the driver's 64-bit idle mask and put it in the legacy 32-bit variable that the userspace reads to know the idle mask. Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin --- dr

[PATCH v7 4/6] tracing: Add a backward-compatibility check for synthetic event creation

(const char *prefix, const char *field_type, + const char *field_name) +{ + /* +* For backward compatibility, the old synthetic event command +* format did not require semicolons, and in order to not +* break user space, that old format must

Re: [PATCH v6 4/6] tracing: Add a backward-compatibility check for synthetic event creation

const char *field_name) > > +{ > > This needs a comment: > > /* >* For backward compatibility, the old format did not require >* semicolons, and not to break user space, that old format > must >* still work. If a new feat

Re: [PATCH v6 4/6] tracing: Add a backward-compatibility check for synthetic event creation

ld *parse_synth_field(int argc, char **argv) > +static int check_field_version(const char *prefix, const char *field_type, > +const char *field_name) > +{ This needs a comment: /* * For backward compatibility, the old format did not require

[PATCH v6 4/6] tracing: Add a backward-compatibility check for synthetic event creation

The synthetic event parsing rework now requires semicolons between synthetic event fields. That requirement breaks existing users who might already have used the old synthetic event command format, so this adds an inner loop that can parse more than one field, if present, between semicolons. For

[PATCH 2/3] habanalabs: fix backward compatibility of idle check

Need to take the lower 32 bits of the driver's 64-bit idle mask and put it in the legacy 32-bit variable that the userspace reads to know the idle mask. Signed-off-by: Oded Gabbay --- drivers/misc/habanalabs/common/habanalabs_ioctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/

[PATCH v5 4/5] tracing: Add a backward-compatibility check for synthetic event creation

/* as of now, every cmd is an old cmd */ + return true; +} + +/** + * get_parseable_cmd - Return a modifiable string for parsing + * @raw_command: The command to start with + * + * Create a cmd string that can be modified by the caller for command + * parsing purposes. If successful, the ca

[PATCH v4 4/5] tracing: Add a backward-compatibility check for synthetic event creation

parsing + * @raw_command: The command to start with + * + * Create a cmd string that can be modified by the caller for command + * parsing purposes. If successful, the caller must free the command + * returned. + * + * The input string will first be checked to see whether or not it can + * be consi

Re: [PATCH v4 1/4] iio: cros_ec: Add sign vector in core for backward compatibility

hes can go safely through > your tree. The order to pick the patches is as follow: > > > 1096491 [v4,1/1] iio: common: cros_ec_sensors: determine protocol version > > 1100922 [v6,1/4] iio: cros_ec: Add sign vector in core for backward > compatibility > 1100924 [v6,3/4

Re: [PATCH v6 1/4] iio: cros_ec: Add sign vector in core for backward compatibility

> } > state->type = state->resp->info.type; > state->loc = state->resp->info.location; > + > + /* Set sign vector, only used for backward compatibility. */ > + memset(state->

Re: [PATCH v4 1/4] iio: cros_ec: Add sign vector in core for backward compatibility

light on this, all the required changes in chrome-platform are now in upstream so all the patches can go safely through your tree. The order to pick the patches is as follow: 1096491 [v4,1/1] iio: common: cros_ec_sensors: determine protocol version 1100922 [v6,1/4] iio: cros_ec: Add sign vector in co

Re: [PATCH v4 1/4] iio: cros_ec: Add sign vector in core for backward compatibility

c_sensors_core.c > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > @@ -66,6 +66,9 @@ int cros_ec_sensors_core_init(struct platform_device *pdev, > } > state->type = state->resp->info.type; > state->loc = state->resp->

[PATCH v6 1/4] iio: cros_ec: Add sign vector in core for backward compatibility

platform_device *pdev, } state->type = state->resp->info.type; state->loc = state->resp->info.location; + + /* Set sign vector, only used for backward compatibility. */ + memset(state->sign, 1, CR

[PATCH v5 1/4] iio: cros_ec: Add sign vector in core for backward compatibility

platform_device *pdev, } state->type = state->resp->info.type; state->loc = state->resp->info.location; + + /* Set sign vector, only used for backward compatibility. */ + memset(state->sign, 1, CR

Re: [PATCH v4 5/5] xen: Add 'xen_nopv' parameter back for backward compatibility

On 2019/7/3 2:13, Boris Ostrovsky wrote: On 7/1/19 1:19 AM, Zhenzhong Duan wrote: Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in kernel-parameters.txt I am not sure we want patch #3, why not do everything in a single patch? Thanks for review. I'll fix all those based on your comme

Re: [PATCH v4 5/5] xen: Add 'xen_nopv' parameter back for backward compatibility

On 7/1/19 1:19 AM, Zhenzhong Duan wrote: > Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in > kernel-parameters.txt I am not sure we want patch #3, why not do everything in a single patch? > > Signed-off-by: Zhenzhong Duan > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: Stefano Stabel

[PATCH v4 5/5] xen: Add 'xen_nopv' parameter back for backward compatibility

Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in kernel-parameters.txt Signed-off-by: Zhenzhong Duan Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov --- Documentation/admin-guide/kernel-parameters.txt | 6 ++

[PATCH v4 1/4] iio: cros_ec: Add sign vector in core for backward compatibility

platform_device *pdev, } state->type = state->resp->info.type; state->loc = state->resp->info.location; + + /* Set sign vector, only used for backward compatibility. */ + memset(state->sign, 1, CR

[PATCH v3 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

platform_device *pdev, } state->type = state->resp->info.type; state->loc = state->resp->info.location; + + /* Set sign vector, only used for backward compatibility. */ + memset(state->sign, 1, CR

Re: [PATCH v2 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

cros_ec_sensors/cros_ec_sensors_core.c > > @@ -66,6 +66,9 @@ int cros_ec_sensors_core_init(struct platform_device > > *pdev, > > } > > state->type = state->resp->info.type; > > state->loc = state->resp->info.location; > > + &g

Re: [PATCH v2 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

Hi, On Thu, Jun 20, 2019 at 7:41 PM Gwendal Grignou wrote: > > To allow cros_ec iio core library to be used with legacy device, add a > vector to rotate sensor data if necessary: legacy devices are not > reporting data in HTML5/Android sensor referential. > > On veyron minnie, check chrome detect

Re: [PATCH v2 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

gt; +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > @@ -66,6 +66,9 @@ int cros_ec_sensors_core_init(struct platform_device *pdev, > } > state->type = state->resp->info.type; > state->loc = state->resp->info

[PATCH v2 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

->type = state->resp->info.type; state->loc = state->resp->info.location; + + /* Set sign vector, only used for backward compatibility. */ + memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS); } return 0; @@ -254,6

Re: [PATCH 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

+66,10 @@ int cros_ec_sensors_core_init(struct platform_device > > *pdev, > > } > > state->type = state->resp->info.type; > > state->loc = state->resp->info.location; > > - } > > > > +

Re: [PATCH 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

state->loc = state->resp->info.location; > - } > > + /* Set sign vector, only used for backward compatibility. */ > + memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS); > + } > return 0; Normally there's a blank line b

[PATCH 1/2] iio: cros_ec: Add sign vector in core for backward compatibility

, } state->type = state->resp->info.type; state->loc = state->resp->info.location; - } + /* Set sign vector, only used for backward compatibility. */ + memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS); +

Re: [PATCH v2] pstore/ram: Improve backward compatibility with older Chromebooks

On Wed, May 8, 2019 at 8:49 AM Douglas Anderson wrote: > When you try to run an upstream kernel on an old ARM-based Chromebook > you'll find that console-ramoops doesn't work. > > Old ARM-based Chromebooks, before > ("ramoops: support upstream {console,pmsg,ftrace}-siz

[PATCH v2] pstore/ram: Improve backward compatibility with older Chromebooks

When you try to run an upstream kernel on an old ARM-based Chromebook you'll find that console-ramoops doesn't work. Old ARM-based Chromebooks, before ("ramoops: support upstream {console,pmsg,ftrace}-size properties") used to create a "ramoops" node at the top level t

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

Hi Doug, On 5/7/19 3:19 PM, Doug Anderson wrote: > Hi, > > On Tue, May 7, 2019 at 3:17 PM Frank Rowand wrote: >> >> On 5/6/19 4:58 PM, Doug Anderson wrote: >>> Hi, >>> >>> On Mon, May 6, 2019 at 2:10 PM Kees Cook wrote: From: Douglas Anderson Date: Fri, May 3, 2019 at 10:48 AM >

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

Hi, On Tue, May 7, 2019 at 3:17 PM Frank Rowand wrote: > > On 5/6/19 4:58 PM, Doug Anderson wrote: > > Hi, > > > > On Mon, May 6, 2019 at 2:10 PM Kees Cook wrote: > >> > >> From: Douglas Anderson > >> Date: Fri, May 3, 2019 at 10:48 AM > >> To: Kees Cook, Anton Vorontsov > >> Cc: , , > >> , , ,

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

On 5/6/19 4:58 PM, Doug Anderson wrote: > Hi, > > On Mon, May 6, 2019 at 2:10 PM Kees Cook wrote: >> >> From: Douglas Anderson >> Date: Fri, May 3, 2019 at 10:48 AM >> To: Kees Cook, Anton Vorontsov >> Cc: , , >> , , , >> Douglas Anderson, Colin Cross, Tony Luck, >> >> >>> When you try to run a

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

On Tue, May 7, 2019 at 9:25 AM Doug Anderson wrote: > On Mon, May 6, 2019 at 2:40 PM Brian Norris wrote: > > The last part of the sentence technically isn't true -- the original > > bindings (notably, with no DT maintainer Reviewed-by) didn't specify > > where such a node should be found: > > > >

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

Hi, On Mon, May 6, 2019 at 2:40 PM Brian Norris wrote: > > On Fri, May 3, 2019 at 10:48 AM Douglas Anderson > wrote: > > When you try to run an upstream kernel on an old ARM-based Chromebook > > you'll find that console-ramoops doesn't work. > > Ooh, nice! I still get annoyed by old depthcharge

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

Hi, On Mon, May 6, 2019 at 4:58 PM Doug Anderson wrote: > > Hi, > > On Mon, May 6, 2019 at 2:10 PM Kees Cook wrote: > > > > From: Douglas Anderson > > Date: Fri, May 3, 2019 at 10:48 AM > > To: Kees Cook, Anton Vorontsov > > Cc: , , > > , , , > > Douglas Anderson, Colin Cross, Tony Luck, > > >

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

Hi, On Mon, May 6, 2019 at 2:10 PM Kees Cook wrote: > > From: Douglas Anderson > Date: Fri, May 3, 2019 at 10:48 AM > To: Kees Cook, Anton Vorontsov > Cc: , , > , , , > Douglas Anderson, Colin Cross, Tony Luck, > > > > When you try to run an upstream kernel on an old ARM-based Chromebook > > yo

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

On Mon, May 6, 2019 at 4:10 PM Kees Cook wrote: > > From: Douglas Anderson > Date: Fri, May 3, 2019 at 10:48 AM > To: Kees Cook, Anton Vorontsov > Cc: , , > , , , > Douglas Anderson, Colin Cross, Tony Luck, > > > > When you try to run an upstream kernel on an old ARM-based Chromebook > > you'll

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

On Fri, May 3, 2019 at 10:48 AM Douglas Anderson wrote: > When you try to run an upstream kernel on an old ARM-based Chromebook > you'll find that console-ramoops doesn't work. Ooh, nice! I still get annoyed by old depthcharge firmware. It's almost as if we should have gotten an upstream binding

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

From: Douglas Anderson Date: Fri, May 3, 2019 at 10:48 AM To: Kees Cook, Anton Vorontsov Cc: , , , , , Douglas Anderson, Colin Cross, Tony Luck, > When you try to run an upstream kernel on an old ARM-based Chromebook > you'll find that console-ramoops doesn't work. > > Old ARM-based Chromebooks,

Re: [PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

On Fri, May 3, 2019 at 10:48 AM Douglas Anderson wrote: > > When you try to run an upstream kernel on an old ARM-based Chromebook > you'll find that console-ramoops doesn't work. > > Old ARM-based Chromebooks, before > ("ramoops: support upstream {console,pmsg,ftrace}-

[PATCH] pstore/ram: Improve backward compatibility with older Chromebooks

When you try to run an upstream kernel on an old ARM-based Chromebook you'll find that console-ramoops doesn't work. Old ARM-based Chromebooks, before ("ramoops: support upstream {console,pmsg,ftrace}-size properties") used to create a "ramoops" node at the top level t

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

F2FS_INLINE_XATTR_ADDRS; >>>>> return CUR_ADDRS_PER_INODE(inode); >>>>> } >>>>> >>>>> It only cares about this inode is inline_xattr or not, so, if we reserve >>>>> 200 >>>>> bytes for dir inode, it will cause incompa

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

; >>>> } >>>> >>>> It only cares about this inode is inline_xattr or not, so, if we reserve >>>> 200 >>>> bytes for dir inode, it will cause incompatibility. >>>> >>>> So we need add this logic into i_inline_xattr

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

ed add this logic into i_inline_xattr_size calculation? Such as: > >> > >> a. new_inode: > >> > >>if (f2fs_sb_has_flexible_inline_xattr(sbi->sb)) { > >> f2fs_bug_on(sbi, !f2fs_has_extra_attr(inode)); > >>if (f2fs_has_inline_xattr) >

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

nline_xattr(sbi->sb)) { >> f2fs_bug_on(sbi, !f2fs_has_extra_attr(inode)); >> if (f2fs_has_inline_xattr) >> xattr_size = sbi->inline_xattr_size; >> } else if (f2fs_has_inline_xattr(inode) || >>

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

On 10/27, Chao Yu wrote: > On 2017/10/26 22:05, Jaegeuk Kim wrote: > > On 10/26, Chao Yu wrote: > >> On 2017/10/26 19:52, Jaegeuk Kim wrote: > >>> On 10/26, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/10/26 18:02, Jaegeuk Kim wrote: > > Hi Chao, > > > > On 10/26, Jaegeuk Kim

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

On 2017/10/26 22:05, Jaegeuk Kim wrote: > On 10/26, Chao Yu wrote: >> On 2017/10/26 19:52, Jaegeuk Kim wrote: >>> On 10/26, Chao Yu wrote: Hi Jaegeuk, On 2017/10/26 18:02, Jaegeuk Kim wrote: > Hi Chao, > > On 10/26, Jaegeuk Kim wrote: >> On 10/26, Chao Yu wrote: >

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

On 10/26, Chao Yu wrote: > On 2017/10/26 19:52, Jaegeuk Kim wrote: > > On 10/26, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2017/10/26 18:02, Jaegeuk Kim wrote: > >>> Hi Chao, > >>> > >>> On 10/26, Jaegeuk Kim wrote: > On 10/26, Chao Yu wrote: > > Hi Jaegeuk, > > > > On 2017/10/2

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

On 2017/10/26 19:52, Jaegeuk Kim wrote: > On 10/26, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2017/10/26 18:02, Jaegeuk Kim wrote: >>> Hi Chao, >>> >>> On 10/26, Jaegeuk Kim wrote: On 10/26, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/10/26 16:42, Jaegeuk Kim wrote: >> Hi Chao, >

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

On 10/26, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/10/26 18:02, Jaegeuk Kim wrote: > > Hi Chao, > > > > On 10/26, Jaegeuk Kim wrote: > >> On 10/26, Chao Yu wrote: > >>> Hi Jaegeuk, > >>> > >>> On 2017/10/26 16:42, Jaegeuk Kim wrote: > Hi Chao, > > It seems this is a critical proble

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

Hi Jaegeuk, On 2017/10/26 18:02, Jaegeuk Kim wrote: > Hi Chao, > > On 10/26, Jaegeuk Kim wrote: >> On 10/26, Chao Yu wrote: >>> Hi Jaegeuk, >>> >>> On 2017/10/26 16:42, Jaegeuk Kim wrote: Hi Chao, It seems this is a critical problem, so let me integrate this patch with your >

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

On 10/26, Jaegeuk Kim wrote: > On 10/26, Jaegeuk Kim wrote: > > Hi Chao, > > > > On 10/26, Jaegeuk Kim wrote: > > > On 10/26, Chao Yu wrote: > > > > Hi Jaegeuk, > > > > > > > > On 2017/10/26 16:42, Jaegeuk Kim wrote: > > > > > Hi Chao, > > > > > > > > > > It seems this is a critical problem, so

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

On 10/26, Jaegeuk Kim wrote: > Hi Chao, > > On 10/26, Jaegeuk Kim wrote: > > On 10/26, Chao Yu wrote: > > > Hi Jaegeuk, > > > > > > On 2017/10/26 16:42, Jaegeuk Kim wrote: > > > > Hi Chao, > > > > > > > > It seems this is a critical problem, so let me integrate this patch > > > > with your > >

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

Hi Chao, On 10/26, Jaegeuk Kim wrote: > On 10/26, Chao Yu wrote: > > Hi Jaegeuk, > > > > On 2017/10/26 16:42, Jaegeuk Kim wrote: > > > Hi Chao, > > > > > > It seems this is a critical problem, so let me integrate this patch with > > > your > > > initial patch "f2fs: support flexible inline xatt

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

On 10/26, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/10/26 16:42, Jaegeuk Kim wrote: > > Hi Chao, > > > > It seems this is a critical problem, so let me integrate this patch with > > your > > initial patch "f2fs: support flexible inline xattr size". > > Let me know, if you have any other concern.

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

Hi Jaegeuk, On 2017/10/26 16:42, Jaegeuk Kim wrote: > Hi Chao, > > It seems this is a critical problem, so let me integrate this patch with your > initial patch "f2fs: support flexible inline xattr size". > Let me know, if you have any other concern. Better. ;) Please add commit message of this

Re: [PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

Hi Chao, It seems this is a critical problem, so let me integrate this patch with your initial patch "f2fs: support flexible inline xattr size". Let me know, if you have any other concern. Thanks, On 10/25, Chao Yu wrote: > Previously, in inode layout, we will always reserve 200 bytes for inline

[PATCH] f2fs: fix to keep backward compatibility of flexible inline xattr feature

Previously, in inode layout, we will always reserve 200 bytes for inline xattr space no matter the inode enables inline xattr feature or not, due to this reason, max inline size of inode is fixed, but now, if inline xattr is not enabled, max inline size of inode will be enlarged by 200 bytes, for r

[PATCH 4.12 09/65] mtd: nand: atmel: Fix DT backward compatibility in pmecc.c

4.12-stable review patch. If anyone has any objections, please let me know. -- From: Boris Brezillon commit 3aa0907675a38498d8f2d343e94207ad28a117cf upstream. PMECC caps extraction from old DT bindings is broken, thus leading to erroneous EL registers offset, which in turn mak

Re: [PATCH] ext4: backward compatibility support for Lustre ea_inode implementation

Andreas, Emoly, I'd appreciate your thoughts; what do you think about Tahsin's patch. Could you give it a try on a file system created with Lustre and let me know how it works for you? Many thanks!! - Ted On Mon, Jul 24, 2017 at 01:13:08PM -0700, Tahsin E

[PATCH] ext4: backward compatibility support for Lustre ea_inode implementation

Original Lustre ea_inode feature did not have ref counts on xattr inodes because there was always one parent that referenced it. New implementation expects ref count to be initialized which is not true for Lustre case. Handle this by detecting Lustre created xattr inode and set its ref count to 1.

Re: [RFC PATCH 1/7] PF driver modified to enable HW filter support, changes works in backward compatibility mode Enable required things in Makefile Enable LZ4 dependecy inside config file

>> #define NIC_MAX_RSS_HASH_BITS 8 >> #define NIC_MAX_RSS_IDR_TBL_SIZE (1 << NIC_MAX_RSS_HASH_BITS) >> +#define NIC_TNS_RSS_IDR_TBL_SIZE 5 > > So you want to use only 5 queues per VF when TNS is enabled, is it ?? > There are 4096 RSS indices in total, for each VF you can use

RE: [RFC PATCH 1/7] PF driver modified to enable HW filter support, changes works in backward compatibility mode Enable required things in Makefile Enable LZ4 dependecy inside config file

, Philip; Linux Netdev List; LAKML Subject: Re: [RFC PATCH 1/7] PF driver modified to enable HW filter support, changes works in backward compatibility mode Enable required things in Makefile Enable LZ4 dependecy inside config file > > #define NIC_MAX_RSS_HASH_BITS 8 >

Re: [RFC PATCH 1/7] PF driver modified to enable HW filter support, changes works in backward compatibility mode Enable required things in Makefile Enable LZ4 dependecy inside config file

> > #define NIC_MAX_RSS_HASH_BITS 8 > #define NIC_MAX_RSS_IDR_TBL_SIZE (1 << NIC_MAX_RSS_HASH_BITS) > +#define NIC_TNS_RSS_IDR_TBL_SIZE 5 So you want to use only 5 queues per VF when TNS is enabled, is it ?? There are 4096 RSS indices in total, for each VF you can use max 32

[RFC PATCH 1/7] PF driver modified to enable HW filter support, changes works in backward compatibility mode Enable required things in Makefile Enable LZ4 dependecy inside config file

--- drivers/net/ethernet/cavium/Kconfig| 1 + drivers/net/ethernet/cavium/thunder/Makefile | 2 +- drivers/net/ethernet/cavium/thunder/nic.h | 203 --- drivers/net/ethernet/cavium/thunder/nic_main.c | 735 ++--- 4 files changed, 804 insertions(+), 137

Re: [PATCH] net: xgene: fix backward compatibility fix

From: Arnd Bergmann Date: Mon, 29 Aug 2016 14:37:14 +0200 > A bugfix for backward compatibility handling introduced undefined > behavior for the case that of_parse_phandle() does not return > a valid entry, as "gcc -Wmaybe-unused" reports: > > drivers/net/ethernet/apm/

[PATCH] net: xgene: fix backward compatibility fix

A bugfix for backward compatibility handling introduced undefined behavior for the case that of_parse_phandle() does not return a valid entry, as "gcc -Wmaybe-unused" reports: drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 'xgene_enet_phy_connect': drivers/ne

[tip:perf/urgent] tools lib traceevent: Fix backward compatibility macros for pevent filter enums

backward compatibility macros for pevent filter enums The return value for pevent_filter_match() is suppose to return FILTER_NONE if the event doesn't have a filter, and FILTER_NOEXIST if there is no filter at all. But the change 41e12e580a7 "tools lib traceevent: Refactor pevent_filter_

[PATCH 3/4] tools lib traceevent: Fix backward compatibility macros for pevent filter enums

t; replaced the return value with PEVENT_ERRNO__* values and added "backward compatibility" macros that used the old names. Unfortunately, the NOEXIST and NONE macros were swapped, and this broke users that use the old return names. Signed-off-by: Steven Rostedt Link:

Re: [PATCH] tools lib traceevent: Fix backward compatibility macros for pevent filter enums

b traceevent: Refactor > pevent_filter_match() to get rid of die()" replaced the return value > with PEVENT_ERRNO__* values and added "backward compatibility" macros > that used the old names. Unfortunately, the NOEXIST and NONE macros were > swapped, and this broke users

[PATCH] tools lib traceevent: Fix backward compatibility macros for pevent filter enums

turn value with PEVENT_ERRNO__* values and added "backward compatibility" macros that used the old names. Unfortunately, the NOEXIST and NONE macros were swapped, and this broke users that use the old return names. Signed-off-by: Steven Rostedt --- tools/lib/traceevent/event-parse.h |

[PATCH 4/7] UBI: fastmap: fix backward compatibility with image_seq

From: Richard Genoud Some old UBI implementations (e.g. U-Boot) have not implemented the image sequence feature. So, when erase blocks are written, the image sequence in the ec header is lost (set to zero). UBI scan_all() takes this case into account (commits 32bc4820287a1a03982979515949e8ea56eac

Re: [PATCH] UBI: fastmap: fix backward compatibility with image_seq

2013/9/27 Richard Weinberger : > Am 27.09.2013 15:16, schrieb Richard Genoud: >> 2013/9/27 Richard Weinberger : >>> Am 27.09.2013 14:51, schrieb Richard Genoud: Some old UBI implementations (e.g. U-Boot) have not implemented the image sequence feature. So, when erase blocks are writt

Re: [PATCH] UBI: fastmap: fix backward compatibility with image_seq

Am 27.09.2013 15:16, schrieb Richard Genoud: > 2013/9/27 Richard Weinberger : >> Am 27.09.2013 14:51, schrieb Richard Genoud: >>> Some old UBI implementations (e.g. U-Boot) have not implemented the image >>> sequence feature. >>> So, when erase blocks are written, the image sequence in the ec heade

Re: [PATCH] UBI: fastmap: fix backward compatibility with image_seq

2013/9/27 Richard Weinberger : > Am 27.09.2013 14:51, schrieb Richard Genoud: >> Some old UBI implementations (e.g. U-Boot) have not implemented the image >> sequence feature. >> So, when erase blocks are written, the image sequence in the ec header >> is lost (set to zero). >> UBI scan_all() takes

Re: [PATCH] UBI: fastmap: fix backward compatibility with image_seq

Am 27.09.2013 14:51, schrieb Richard Genoud: > Some old UBI implementations (e.g. U-Boot) have not implemented the image > sequence feature. > So, when erase blocks are written, the image sequence in the ec header > is lost (set to zero). > UBI scan_all() takes this case into account (commits > 32b

[PATCH] UBI: fastmap: fix backward compatibility with image_seq

Some old UBI implementations (e.g. U-Boot) have not implemented the image sequence feature. So, when erase blocks are written, the image sequence in the ec header is lost (set to zero). UBI scan_all() takes this case into account (commits 32bc4820287a1a03982979515949e8ea56eac641 and 2eadaad67b2b6bd

[PATCH 1/5] nohz: Fix old dynticks idle Kconfig backward compatibility

In order to enforce backward compatibility with older config files, we want the new dynticks-idle Kconfig entry to default its value to the one of the old CONFIG_NO_HZ symbol if present. Namely we want: config NO_HZ # old obsolete dynticks idle symbol bool config

Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

On Mon, Nov 12, 2007 at 03:47:02AM +0100, Roman Zippel wrote: > Hi, > > On Sat, 10 Nov 2007, Sam Ravnborg wrote: > > > As discussed in another thread the right thing is to add a generic solution > > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al. > > Could you please poin

Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

Hi, On Sat, 10 Nov 2007, Sam Ravnborg wrote: > As discussed in another thread the right thing is to add a generic solution > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al. Could you please point me to this discussion? Thanks. bye, Roman - To unsubscribe from this list:

Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

On Sun, Nov 11, 2007 at 06:09:45AM +0100, Adrian Bunk wrote: > On Sat, Nov 10, 2007 at 09:40:38PM +0100, Sam Ravnborg wrote: > > > As discussed in another thread the right thing is to add a generic solution > > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al. > >... > > I s

Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

On Sat, Nov 10, 2007 at 09:40:38PM +0100, Sam Ravnborg wrote: > As discussed in another thread the right thing is to add a generic solution > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al. >... I seriously question this would be "the right thing". 32/64bit isn't that spe

Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

gt; > > > First step was to teach kconfig how to force 64BIT to a specific value. > > The x86 Kconfig file needed a small twist to use 64BIT as the symbol > > to seelct 32 or 64 bit. > > Then it was simple to add backward compatibility ARCH= settings. > > >

Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

e. > The x86 Kconfig file needed a small twist to use 64BIT as the symbol > to seelct 32 or 64 bit. > Then it was simple to add backward compatibility ARCH= settings. > > The patchset is not yet pushed out - I will await a bit feedback first. > > Shortlog and diffstat. &g

[PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

seelct 32 or 64 bit. Then it was simple to add backward compatibility ARCH= settings. The patchset is not yet pushed out - I will await a bit feedback first. Shortlog and diffstat. kconfig: factor out code in confdata.c kconfig: use $K64BIT to set 64BIT with all*config targets x86

[PATCH 10/11] x86: drop backward compatibility symlinks to i386/boot and x86_64/boot

This is the final step of full transition to the unified x86 architecture from the build system point of view. Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/x86/Makefile_32 |2 -- arch/x86/Makefile_64 |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/x8

Backward compatibility

Hello guys, I am trying to set up a big jump: going from RedHat 6.1 kernel 2.2.12 to RedHat 7.0 kernel 2.2.16. For backward compatibility, I would like to compile an ANSI C application on 7.0 and run on 6.1. How is it possible ? Do I need to copy /lib/libc-2.1.92.so (the one of 7.0) on 6.1