Re: [PATCH 3/3] thermal: max77620: Add thermal driver for reporting junction temp

[Eduardo Valentin]

Hello Laxman,

Thanks for working on this. Impressed how simplified these drivers are
becoming. I really liked you added the so waited devm_ helpers. Very
minor comments as follows (now that you will send a new version anyway).

On Fri, Mar 04, 2016 at 07:10:10PM +0530, Laxman Dewangan wrote:
> Maxim Semiconductor Max77620 supports alarm interrupts when
> its die temperature crosses 120C and 140C. These threshold
> temperatures are not configurable.
> 
> Add thermal driver to register PMIC die temperature as thermal
> zone sensor and capture the die temperature warning interrupts
> to notifying the client.

Are any of these critical?

> 
> Signed-off-by: Laxman Dewangan 
> ---
>  drivers/thermal/Kconfig|   9 +++
>  drivers/thermal/Makefile   |   1 +
>  drivers/thermal/thermal-max77620.c | 151 
> +

Given that it is a DT based driver, please add also a binding entry
under Documentation/devicetree/bindings/thermal/


>  3 files changed, 161 insertions(+)
>  create mode 100644 drivers/thermal/thermal-max77620.c
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 5e7c97a..faba1a3 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -194,6 +194,15 @@ config IMX_THERMAL
> cpufreq is used as the cooling device to throttle CPUs when the
> passive trip is crossed.
>  
> +config MAX77620_THERMAL
> + tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
> + depends on MFD_MAX77620

Can this be COMPILE_TEST'ed?

> + depends on OF

> + help
> +   Support for die junction temperature warning alarm for Maxim
> +   Semiconductor PMIC MAX77620 device. Device generates alert
> +   signal/interrupt when die temperature cross its threshold.
> +

Somehow checkpatch.pl --strict is complaining about this entry. Can you
please check?


>  config SPEAR_THERMAL
>   tristate "SPEAr thermal sensor driver"
>   depends on PLAT_SPEAR || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8e9cbc3..c6bc2bd 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_DOVE_THERMAL)  += dove_thermal.o
>  obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
>  obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
>  obj-$(CONFIG_IMX_THERMAL)+= imx_thermal.o
> +obj-$(CONFIG_MAX77620_THERMAL)   += thermal-max77620.o
>  obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
>  obj-$(CONFIG_INTEL_POWERCLAMP)   += intel_powerclamp.o
>  obj-$(CONFIG_X86_PKG_TEMP_THERMAL)   += x86_pkg_temp_thermal.o
> diff --git a/drivers/thermal/thermal-max77620.c 
> b/drivers/thermal/thermal-max77620.c
> new file mode 100644
> index 000..846da62
> --- /dev/null
> +++ b/drivers/thermal/thermal-max77620.c
> @@ -0,0 +1,151 @@
> +/*
> + * Junction temperature thermal driver for Maxim Max77620.
> + *
> + * Copyright (c) 2016, NVIDIA CORPORATION.  All rights reserved.
> + *
> + * Author: Laxman Dewangan 
> + *  Mallikarjun Kasoju 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX77620_NORMAL_OPERATING_TEMP   10
> +#define MAX77620_TJALARM1_TEMP   12
> +#define MAX77620_TJALARM1_TEMP   14
> +
> +struct max77620_therm_info {
> + struct device   *dev;
> + struct regmap   *rmap;
> + struct thermal_zone_device  *tz_device;
> + int irq_tjalarm1;
> + int irq_tjalarm2;
> +};
> +
> +static int max77620_thermal_read_temp(void *data, int *temp)
> +{
> + struct max77620_therm_info *mtherm = data;
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(mtherm->rmap, MAX77620_REG_STATLBT, );
> + if (ret < 0) {
> + dev_err(mtherm->dev, "Failed to read STATLBT, %d\n", ret);
> + return -EINVAL;
> + }
> +
> + if (val & MAX77620_IRQ_TJALRM2_MASK)
> + *temp = MAX77620_TJALARM2_TEMP;
> + else if (val & MAX77620_IRQ_TJALRM1_MASK)
> + *temp = MAX77620_TJALARM1_TEMP;
> + else
> + *temp = MAX77620_NORMAL_OPERATING_TEMP;

So, no way at all to get a temp?

> + return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops max77620_thermal_ops = {
> + .get_temp = max77620_thermal_read_temp,
> +};
> +
> +static irqreturn_t max77620_thermal_irq(int irq, void *data)
> +{
> + struct max77620_therm_info *mtherm = data;
> +
> + if (irq == mtherm->irq_tjalarm1)
> + 

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[Khalid Aziz]

On 03/08/2016 01:27 PM, David Miller wrote:

From: Khalid Aziz 
Date: Tue, 8 Mar 2016 13:16:11 -0700


On 03/08/2016 12:57 PM, David Miller wrote:

From: Khalid Aziz 
Date: Mon, 7 Mar 2016 14:06:43 -0700


Good questions. Isn't set of valid VAs already constrained by VA_BITS
(set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
are already not using the top 4 bits. Please correct me if I am wrong.


Another limiting constraint is the number of address bits coverable by
the 4-level page tables we use.  And this is sign extended so we have
a top-half and a bottom-half with a "hole" in the center of the VA
space.

I want some clarification on the top bits during ADI accesses.

If ADI is enabled, then the top bits of the virtual address are
intepreted as tag bits.  Once "verified" with the ADI settings, what
happense to these tag bits?  Are they dropped from the virtual address
before being passed down the TLB et al. for translations?


Bits 63-60 (tag bits) are dropped from the virtual address before
being passed down the TLB for translation when PSTATE.mcde = 1.


Ok and you said that values 15 and 0 are special.

I'm just wondering if this means you can't really use ADI mappings in
the top half of the 64-bit address space.  If the bits are dropped, they
will be zero, but they need to be all 1's for the top-half of the VA
space since it's sign extended.



According to the manual when PSTATE.mcde=1, bits 63:60 of the virtual 
address of any load or store (using virtual address) are masked before 
being sent to memory system which includes MMU. Hardware TSB walker 
masks bits 63:60 and then sign extends from bit 59 before generating TSB 
pointer and before comparison to TSB TTE VAs but the virtual address in 
the TTE tag that is written to DTLB is masked and not sign extended. 
Manual also states that for implementations that fully support 60 bits 
or more of virtual address, they must sign-extend virtual address in TSB 
TTE tag.


--
Khalid

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Khalid Aziz 
Date: Tue, 8 Mar 2016 13:16:11 -0700

> On 03/08/2016 12:57 PM, David Miller wrote:
>> From: Khalid Aziz 
>> Date: Mon, 7 Mar 2016 14:06:43 -0700
>>
>>> Good questions. Isn't set of valid VAs already constrained by VA_BITS
>>> (set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
>>> are already not using the top 4 bits. Please correct me if I am wrong.
>>
>> Another limiting constraint is the number of address bits coverable by
>> the 4-level page tables we use.  And this is sign extended so we have
>> a top-half and a bottom-half with a "hole" in the center of the VA
>> space.
>>
>> I want some clarification on the top bits during ADI accesses.
>>
>> If ADI is enabled, then the top bits of the virtual address are
>> intepreted as tag bits.  Once "verified" with the ADI settings, what
>> happense to these tag bits?  Are they dropped from the virtual address
>> before being passed down the TLB et al. for translations?
> 
> Bits 63-60 (tag bits) are dropped from the virtual address before
> being passed down the TLB for translation when PSTATE.mcde = 1.

Ok and you said that values 15 and 0 are special.

I'm just wondering if this means you can't really use ADI mappings in
the top half of the 64-bit address space.  If the bits are dropped, they
will be zero, but they need to be all 1's for the top-half of the VA
space since it's sign extended.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[Khalid Aziz]

On 03/08/2016 12:57 PM, David Miller wrote:

From: Khalid Aziz 
Date: Mon, 7 Mar 2016 14:06:43 -0700


Good questions. Isn't set of valid VAs already constrained by VA_BITS
(set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
are already not using the top 4 bits. Please correct me if I am wrong.


Another limiting constraint is the number of address bits coverable by
the 4-level page tables we use.  And this is sign extended so we have
a top-half and a bottom-half with a "hole" in the center of the VA
space.

I want some clarification on the top bits during ADI accesses.

If ADI is enabled, then the top bits of the virtual address are
intepreted as tag bits.  Once "verified" with the ADI settings, what
happense to these tag bits?  Are they dropped from the virtual address
before being passed down the TLB et al. for translations?


Bits 63-60 (tag bits) are dropped from the virtual address before being 
passed down the TLB for translation when PSTATE.mcde = 1.


--
Khalid



If not, then this means you have to map ADI memory to the correct
location so that the tags match up.

And if that's the case, if you really wanted to mix tags within a
single page, you'd have to map that page several times, once for each
and every cacheline granular tag you'd like to use within that page.



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] fat: add config option to set UTF-8 mount option by default

[OGAWA Hirofumi]

"Maciej S. Szmigiero"  writes:

> FAT has long supported its own default file name encoding
> config setting, separate from CONFIG_NLS_DEFAULT.
>
> However, if UTF-8 encoded file names are desired FAT
> character set should not be set to utf8 since this would
> make file names case sensitive even if case insensitive
> matching is requested.
> Instead, "utf8" mount options should be provided to enable
> UTF-8 file names in FAT file system.
>
> Unfortunately, there was no possibility to set the default
> value of this option so on UTF-8 system "utf8" mount option
> had to be added manually to most FAT mounts.
>
> This patch adds config option to set such default value.
>
> Signed-off-by: Maciej S. Szmigiero 

Acked-by: OGAWA Hirofumi 

> ---
> Changes from v1: use IS_ENABLED() macro to simplify code
>
>  Documentation/filesystems/vfat.txt |  7 ---
>  fs/fat/Kconfig | 18 +-
>  fs/fat/inode.c |  4 +++-
>  3 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/filesystems/vfat.txt 
> b/Documentation/filesystems/vfat.txt
> index 223c32171dcc..cf51360e3a9f 100644
> --- a/Documentation/filesystems/vfat.txt
> +++ b/Documentation/filesystems/vfat.txt
> @@ -56,9 +56,10 @@ iocharset= -- Character set to use for converting 
> between the
>you should consider the following option instead.
>  
>  utf8=   -- UTF-8 is the filesystem safe version of Unicode that
> -  is used by the console.  It can be enabled for the
> -  filesystem with this option. If 'uni_xlate' gets set,
> -  UTF-8 gets disabled.
> +  is used by the console. It can be enabled or disabled
> +  for the filesystem with this option.
> +  If 'uni_xlate' gets set, UTF-8 gets disabled.
> +  By default, FAT_DEFAULT_UTF8 setting is used.
>  
>  uni_xlate= -- Translate unhandled Unicode characters to special
>escaped sequences.  This would let you backup and
> diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
> index 182f9ffe2b51..3ff1772f612e 100644
> --- a/fs/fat/Kconfig
> +++ b/fs/fat/Kconfig
> @@ -93,8 +93,24 @@ config FAT_DEFAULT_IOCHARSET
> that most of your FAT filesystems use, and can be overridden
> with the "iocharset" mount option for FAT filesystems.
> Note that "utf8" is not recommended for FAT filesystems.
> -   If unsure, you shouldn't set "utf8" here.
> +   If unsure, you shouldn't set "utf8" here - select the next option
> +   instead if you would like to use UTF-8 encoded file names by default.
> See  for more information.
>  
> Enable any character sets you need in File Systems/Native Language
> Support.
> +
> +config FAT_DEFAULT_UTF8
> + bool "Enable FAT UTF-8 option by default"
> + depends on VFAT_FS
> + default n
> + help
> +   Set this if you would like to have "utf8" mount option set
> +   by default when mounting FAT filesystems.
> +
> +   Even if you say Y here can always disable UTF-8 for
> +   particular mount by adding "utf8=0" to mount options.
> +
> +   Say Y if you use UTF-8 encoding for file names, N otherwise.
> +
> +   See  for more information.
> diff --git a/fs/fat/inode.c b/fs/fat/inode.c
> index a5599052116c..226281068a46 100644
> --- a/fs/fat/inode.c
> +++ b/fs/fat/inode.c
> @@ -1127,7 +1127,7 @@ static int parse_options(struct super_block *sb, char 
> *options, int is_vfat,
>   }
>   opts->name_check = 'n';
>   opts->quiet = opts->showexec = opts->sys_immutable = opts->dotsOK =  0;
> - opts->utf8 = opts->unicode_xlate = 0;
> + opts->unicode_xlate = 0;
>   opts->numtail = 1;
>   opts->usefree = opts->nocase = 0;
>   opts->tz_set = 0;
> @@ -1135,6 +1135,8 @@ static int parse_options(struct super_block *sb, char 
> *options, int is_vfat,
>   opts->errors = FAT_ERRORS_RO;
>   *debug = 0;
>  
> + opts->utf8 = IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8) && is_vfat;
> +
>   if (!options)
>   goto out;
>  

-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

[Oliver Hartkopp]

On 03/08/2016 01:48 PM, Ramesh Shanmugasundaram wrote:

>> In fact you provided a CAN driver which is "CAN-FD-only".
> 
> Yes. That's the status of current submission.
> 
>> We did not had that before but there's a solution for this kind of setup.
>>
>> There is a similar case with CAN_CTRLMODE_FD_NON_ISO we had on the M_CAN
>> driver which only provides non-ISO configuration for the supported IP core
>> and _no_ option to _change_ this value:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id
>> =6cfda7fbebe8a4fd33ea5722fa0212f98f643c35
>>
>> If you would do it similar in rcar_canfd.c with
>>
>> /* CAN_CTRLMODE_FD is fixed with R-Car CAN FD */
>> priv->can.ctrlmode = CAN_CTRLMODE_FD;
>>
>> and remove CAN_CTRLMODE_FD from the priv->can.ctrlmode_supported
>> assignment then it should do the entire configuration process correctly
>> for you.
>> Including the proper tests for the two bitrates.
>> (see open_candev() in linux/drivers/net/can/dev.c)
>>
>> Right?
> 
> I did try this option earlier but there are two problems with this method.
> 
> 1) Below configuration is not possible
> 
> ip link set can0 up type can bitrate 100 dbitrate 100 fd on
> 
> "fd on" -> This is not allowed because CAN_CTRLMODE_FD bit is not set in 
> ctrlmode_supported.
> 
> 2) If I ignore "fd on", my interface MTU stays as CAN_MTU only. If I have to 
> change the MTU alone to CANFD_MTU using another netlink message, it again 
> checks ctrlmode_supported where it would fail. I have the option of providing 
> my own change_mtu function & ignore this check but two configuration messages 
> are required for my driver alone :-(.
> 
> Both these anomalies are addressed with the current check I have. 

Oh - you are right with complaining about this inconsistency.

Can you check my RFC patch for Linux stable I just sent on the mailing list?
http://marc.info/?l=linux-can=145745724917976=2

Many thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 11/11] ARM: dts: Add Altera Arria10 L2 Cache EDAC devicetree entry

[Thor Thayer]

Hi Dinh,

On 03/08/2016 08:50 AM, Dinh Nguyen wrote:



On 03/07/2016 01:43 PM, ttha...@opensource.altera.com wrote:

From: Thor Thayer 

Add the device tree entries needed to support the Altera L2
cache EDAC on the Arria10 chip.

Signed-off-by: Thor Thayer 
---
v2 Match register value (l2-ecc@ffd06010)
---
  arch/arm/boot/dts/socfpga_arria10.dtsi |   14 ++
  1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi 
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index cce9e50..44aeb3f 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -599,6 +599,20 @@
reg = <0xffe0 0x4>;
};

+   eccmgr: eccmgr@ffd06090 {
+   compatible = "altr,socfpga-ecc-manager";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   l2-ecc@ffd06010 {
+   compatible = "altr,socfpga-a10-l2-ecc";
+   reg = <0xffd06010 0x4>;
+   interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>,
+<0 0 IRQ_TYPE_LEVEL_HIGH>;
+   };
+   };
+


Just checking if these addresses are correct. The eccmgr is at
0xffd06090, but the l2-ecc is at 0xffd06010? I would have thought from
the placement the l2-ecc address would be inside the eccmgr's address?

Dinh



Yes, this is confusing and I'll clarify/reorganize in the next series. 
The eccmgr is pointing to the ECC IRQ mask bits. These registers and the 
L2 ECC registers are organized in different areas within the system manager.


I'm actually redoing the series since the Arria10 IRQ handling is 
significantly different.


Since this change will affect the bindings and dti (the eccmgr will have 
the IRQs), please disregard this series.


Sorry for the noise.

Thor
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 07/11] EDAC, altera: Add status offset & masks

[Thor Thayer]

Hi Boris,

On 03/07/2016 01:43 PM, ttha...@opensource.altera.com wrote:

From: Thor Thayer 

In preparation for the Arria10 peripheral ECCs, the IRQ
status needs to be determined because the IRQs are shared.
The IRQ status register is read to determine if the IRQ
was for this ECC peripheral. Cyclone5 and Arria5 have
dedicated IRQs so the confirmation mechanism is not
required and the mask is set to 0.

Signed-off-by: Thor Thayer 
---
v2: Split large patch into smaller patches. Determine
 if IRQ matches this ECC peripheral before handling it.
---
  drivers/edac/altera_edac.c |   41 +++--
  drivers/edac/altera_edac.h |3 +++
  2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index fd73a77..11b7291 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -556,19 +556,32 @@ static irqreturn_t altr_edac_device_handler(int irq, void 
*dev_id)
struct edac_device_ctl_info *dci = dev_id;
struct altr_edac_device_dev *drvdata = dci->pvt_info;
const struct edac_device_prv_data *priv = drvdata->data;
+   void __iomem *status_addr = drvdata->status + priv->err_status_ofst;
void __iomem *clear_addr = drvdata->status + priv->clear_err_ofst;

+   /*
+* CycloneV is directly mapped to a specific IRQ. Arria10
+* shares the IRQ with other ECCs so we must match first.
+*/
if (irq == drvdata->sb_irq) {
-   if (priv->ce_clear_mask)
-   writel(priv->ce_clear_mask, clear_addr);
-   edac_device_handle_ce(dci, 0, 0, drvdata->edac_dev_name);
-   ret_value = IRQ_HANDLED;
+   if (!priv->ce_status_mask ||
+   (priv->ce_status_mask & readl(status_addr))) {
+   if (priv->ce_clear_mask)
+   writel(priv->ce_clear_mask, clear_addr);
+   edac_device_handle_ce(dci, 0, 0,
+ drvdata->edac_dev_name);
+   ret_value = IRQ_HANDLED;
+   }
} else if (irq == drvdata->db_irq) {
-   if (priv->ue_clear_mask)
-   writel(priv->ue_clear_mask, clear_addr);
-   edac_device_handle_ue(dci, 0, 0, drvdata->edac_dev_name);
-   panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
-   ret_value = IRQ_HANDLED;
+   if (!priv->ue_status_mask ||
+   (priv->ue_status_mask & readl(status_addr))) {
+   if (priv->ue_clear_mask)
+   writel(priv->ue_clear_mask, clear_addr);
+   edac_device_handle_ue(dci, 0, 0,
+ drvdata->edac_dev_name);
+   panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
+   ret_value = IRQ_HANDLED;
+   }
} else {
WARN_ON(1);
}



While working on subsequent ECC components to upstream, I realized that 
the above is not an optimal solution for Arria10.


The Arria10 is significantly different from the Cyclone5/Arria5 and 
therefore should be it's own implementation.


Please disregard this patch series. I'll redo the series with a 
different IRQ implementation that is cleaner - it will be closer to the 
Xgene driver.


Sorry for the noise.

Thor



@@ -882,6 +895,10 @@ const struct edac_device_prv_data ocramecc_data = {
.ce_clear_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_SERR),
.ue_clear_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_DERR),
.clear_err_ofst = ALTR_OCR_ECC_REG_OFFSET,
+   /* Cyclone5 & Arria5 have separate IRQs so status = 0 */
+   .ce_status_mask = 0,
+   .ue_status_mask = 0,
+   .err_status_ofst = 0,
.dbgfs_name = "altr_ocram_trigger",
.alloc_mem = ocram_alloc_mem,
.free_mem = ocram_free_mem,
@@ -957,7 +974,11 @@ const struct edac_device_prv_data l2ecc_data = {
.setup = altr_l2_check_deps,
.ce_clear_mask = 0,
.ue_clear_mask = 0,
-   .clear_err_ofst = ALTR_L2_ECC_REG_OFFSET,
+   .clear_err_ofst = ALTR_MAN_GRP_L2_ECC_OFFSET,
+   /* Cyclone5 & Arria5 have separate IRQs so status = 0 */
+   .ce_status_mask = 0,
+   .ue_status_mask = 0,
+   .err_status_ofst = 0,
.dbgfs_name = "altr_l2_trigger",
.alloc_mem = l2_alloc_mem,
.free_mem = l2_free_mem,
diff --git a/drivers/edac/altera_edac.h b/drivers/edac/altera_edac.h
index b262f74..43e0dae 100644
--- a/drivers/edac/altera_edac.h
+++ b/drivers/edac/altera_edac.h
@@ -226,6 +226,9 @@ struct edac_device_prv_data {
int ce_clear_mask;
int ue_clear_mask;
int clear_err_ofst;
+   int ce_status_mask;
+   int ue_status_mask;
+   int err_status_ofst;
char 

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Tue, 8 Mar 2016 10:39:22 -0300
Mauro Carvalho Chehab  escreveu:

> Em Tue, 08 Mar 2016 05:13:13 -0700
> Dan Allen  escreveu:
> 
> > On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab <  
> > mche...@osg.samsung.com> wrote:
> >   
> > > pandoc did a really crap job on the conversion. To convert this
> > > into something useful, we'll need to spend a lot of time, as it lost
> > > most of the cross-references, as they were defined via DocBook macros.
> > >
> > 
> > I agree pandoc creates crappy AsciiDoc. We have a much better converter in
> > the works called DocBookRx.
> > 
> > https://github.com/opendevise/docbookrx
> > 
> > It has converted several very serious DocBook documents and we're
> > continuing to improve it. It's also a lot easier to hack than pandoc.  
> 
> Didn't work:
> 
> $ ./bin/docbookrx ~/devel/docbook_test/v4l2.xml 
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.

I tried to use docbookrx for the bits that were not properly converted,
like the manpage-like pages:

$  ../docbookrx/bin/docbookrx Documentation/DocBook/media/v4l/func-ioctl.xml
No visitor defined for ! Skipping.

Dan, if you want to take a look on what's going wrong here, 
the XML I'm trying to convert is:


https://git.linuxtv.org/media_tree.git/tree/Documentation/DocBook/media/v4l/func-ioctl.xml

If this would work, it should be generating something like:
https://git.linuxtv.org/mchehab/asciidoc-poc.git/tree/func-ioctl.adoc

Pandoc failed to fully convert it, but at least it left all the texts,
with prevented rewriting it from scratch. This is the manual fix
I applied to it:

https://git.linuxtv.org/mchehab/asciidoc-poc.git/commit/func-ioctl.adoc?id=801d336c3742f26731e08c284290c32c0b4632fc

FYI, we have 133 xml files at the media uAPI doc with refmeta.

-- 
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 10/11] ARM: socfpga: Enable Arria10 L2 cache ECC on startup

[Dinh Nguyen]

On 03/07/2016 01:43 PM, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Enable ECC for Arria10 L2 cache on machine startup. The ECC has to be
> enabled before data is stored in memory otherwise the ECC will fail
> on reads.
> Use DT_MACHINE to select Arria10 L2 cache function.
> 
> Signed-off-by: Thor Thayer 
> ---
> v2: Split into 2 separate functions selected with DT_MACHINE.
> ---
>  arch/arm/mach-socfpga/core.h |1 +
>  arch/arm/mach-socfpga/l2_cache.c |   49 
> ++
>  arch/arm/mach-socfpga/socfpga.c  |   10 +++-
>  3 files changed, 59 insertions(+), 1 deletion(-)
> 

Acked-by: Dinh Nguyen 

Thanks,
Dinh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Tue, 08 Mar 2016, Dan Allen  wrote:
> That's not entirely true. First, you can pre-split at the source level
> using includes and generate output for each of the masters. That's what I
> tend to do and it works really well since these are logical split points.

I need to look into this again. Is there a specific option or directive
to produce split output for includes? When I tried this, the result was
just one big output file. (And indeed we'd need both. Some includes we
want embedded, some includes should produce separate outputs.)

>> That actually makes choosing asciidoc harder, because
>> requiring another language environment complicates, not simplifies, the
>> toolchain. I'd really like to lower the bar for building the
>> documentation, for everyone, so much so that it becomes part of the
>> normal checks for patch inclusion.
>
> Pardon my bluntness here, but I don't buy that argument. This is Linux.
> Installing software couldn't be simpler, and we're talking about an
> extremely well supported language (Ruby).

Granted, that part works for me. I'm not so sensitive to the
dependencies; others may disagree.

> I think it's a huge exaggeration to say that Asciidoctor is any harder to
> install than AsciiDoc Python. It's also a heck of a lot smaller in size
> since AsciiDoc Python pulls in hundreds of MB of LaTeX packages.

For me, the comparison is really between Sphinx and Asciidoctor, not so
much doc vs. doctor. The native output format and extension support in
Sphinx is appealing; I am not yet convinced we could manage with
Asciidoctor but without DocBook. The extension offering seems better in
Sphinx.

> Whatever you decide, I wish you all the best with your documentation
> efforts!

Thanks!

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] fat: add config option to set UTF-8 mount option by default

[Maciej S. Szmigiero]

FAT has long supported its own default file name encoding
config setting, separate from CONFIG_NLS_DEFAULT.

However, if UTF-8 encoded file names are desired FAT
character set should not be set to utf8 since this would
make file names case sensitive even if case insensitive
matching is requested.
Instead, "utf8" mount options should be provided to enable
UTF-8 file names in FAT file system.

Unfortunately, there was no possibility to set the default
value of this option so on UTF-8 system "utf8" mount option
had to be added manually to most FAT mounts.

This patch adds config option to set such default value.

Signed-off-by: Maciej S. Szmigiero 
---
Changes from v1: use IS_ENABLED() macro to simplify code

 Documentation/filesystems/vfat.txt |  7 ---
 fs/fat/Kconfig | 18 +-
 fs/fat/inode.c |  4 +++-
 3 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/Documentation/filesystems/vfat.txt 
b/Documentation/filesystems/vfat.txt
index 223c32171dcc..cf51360e3a9f 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -56,9 +56,10 @@ iocharset= -- Character set to use for converting 
between the
 you should consider the following option instead.
 
 utf8=   -- UTF-8 is the filesystem safe version of Unicode that
-is used by the console.  It can be enabled for the
-filesystem with this option. If 'uni_xlate' gets set,
-UTF-8 gets disabled.
+is used by the console. It can be enabled or disabled
+for the filesystem with this option.
+If 'uni_xlate' gets set, UTF-8 gets disabled.
+By default, FAT_DEFAULT_UTF8 setting is used.
 
 uni_xlate= -- Translate unhandled Unicode characters to special
 escaped sequences.  This would let you backup and
diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 182f9ffe2b51..3ff1772f612e 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -93,8 +93,24 @@ config FAT_DEFAULT_IOCHARSET
  that most of your FAT filesystems use, and can be overridden
  with the "iocharset" mount option for FAT filesystems.
  Note that "utf8" is not recommended for FAT filesystems.
- If unsure, you shouldn't set "utf8" here.
+ If unsure, you shouldn't set "utf8" here - select the next option
+ instead if you would like to use UTF-8 encoded file names by default.
  See  for more information.
 
  Enable any character sets you need in File Systems/Native Language
  Support.
+
+config FAT_DEFAULT_UTF8
+   bool "Enable FAT UTF-8 option by default"
+   depends on VFAT_FS
+   default n
+   help
+ Set this if you would like to have "utf8" mount option set
+ by default when mounting FAT filesystems.
+
+ Even if you say Y here can always disable UTF-8 for
+ particular mount by adding "utf8=0" to mount options.
+
+ Say Y if you use UTF-8 encoding for file names, N otherwise.
+
+ See  for more information.
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index a5599052116c..226281068a46 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -1127,7 +1127,7 @@ static int parse_options(struct super_block *sb, char 
*options, int is_vfat,
}
opts->name_check = 'n';
opts->quiet = opts->showexec = opts->sys_immutable = opts->dotsOK =  0;
-   opts->utf8 = opts->unicode_xlate = 0;
+   opts->unicode_xlate = 0;
opts->numtail = 1;
opts->usefree = opts->nocase = 0;
opts->tz_set = 0;
@@ -1135,6 +1135,8 @@ static int parse_options(struct super_block *sb, char 
*options, int is_vfat,
opts->errors = FAT_ERRORS_RO;
*debug = 0;
 
+   opts->utf8 = IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8) && is_vfat;
+
if (!options)
goto out;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Tue, 08 Mar 2016 05:13:13 -0700
Dan Allen  escreveu:

> On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab <
> mche...@osg.samsung.com> wrote:  
> 
> > pandoc did a really crap job on the conversion. To convert this
> > into something useful, we'll need to spend a lot of time, as it lost
> > most of the cross-references, as they were defined via DocBook macros.
> >  
> 
> I agree pandoc creates crappy AsciiDoc. We have a much better converter in
> the works called DocBookRx.
> 
> https://github.com/opendevise/docbookrx
> 
> It has converted several very serious DocBook documents and we're
> continuing to improve it. It's also a lot easier to hack than pandoc.

Didn't work:

$ ./bin/docbookrx ~/devel/docbook_test/v4l2.xml 
No visitor defined for ! Skipping.
No visitor defined for ! Skipping.
No visitor defined for ! Skipping.
No visitor defined for ! Skipping.
No visitor defined for ! Skipping.


> 
> -Dan
> 
> 


-- 
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Tue, 08 Mar 2016 05:09:40 -0700
Dan Allen  escreveu:

> Jani wrote:
> 
> > there was no support for chunked, or split
> > to chapters, HTML, and the single page result was simply way too big.
> >  
> 
> That's not entirely true. First, you can pre-split at the source level
> using includes and generate output for each of the masters. That's what I
> tend to do and it works really well since these are logical split points.

The problem on pre-splitting the documents and process them in separate
is that this will break cross-references. At the media uAPI Docbook,
we use a lot of cross references.

Btw, we use a lot of includes. Currently, it has 187 separate files.

We even parse the header files looking for typedefs, structs, enums,
#defines and functions, in order to produce a document that will
cross-reference the documentation.

> Second, there is a custom converter in the works to split post-generate
> (which is really what we're talking about when we compare it to the DocBook
> toolchain).
> 
> https://github.com/asciidoctor/asciidoctor-extensions-lab/blob/master/lib/multipage-html5-converter.rb
> 
> It's just a prototype, but proves it is possible by design.

I didn't test it, but I saw some comments at the web that the part
that would handle cross-references between files is not ready.

> Personally, I don't like most chunked HTML approaches because they split
> arbitrarily. We are trying to find the right balance so that the output is
> actually sensible. There's still work to do, but there are options in the
> meantime.

Well, if it is capable of creating one chunk per include file, and do
cross-references between chunks, this would work for media UAPI book.

Yet, it would be good to have the multi-chunk extension packaged
on major distros, as I don't like the idea of installing it without
using my distro's package manager.

-- 
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

[Ramesh Shanmugasundaram]

Hi Oliver,

Thanks for the comments.

> On 08.03.2016 09:57, Ramesh Shanmugasundaram wrote:
> 
> >
> > As you mentioned further down, when a user does this
> >
> > "ip link set can0 up type can bitrate 100"
> >
> > the intention is to put the controller in CAN 2.0 mode. Even if we use a
> status flag or copy the data bitrate equal to the nominal bitrate, what
> would it achieve? It still cannot be a CAN 2.0 node - it is a CAN FD node
> configured with same nominal & data bitrate.
> >
> > This is why I have this check in ndo_open, so that the user is aware it
> is a CAN FD node always and avoid misconfiguration like above with
> EOPNOTSUPP.
> >
> 
> ok - got it now.
> 
> In fact you provided a CAN driver which is "CAN-FD-only".

Yes. That's the status of current submission.

> We did not had that before but there's a solution for this kind of setup.
> 
> There is a similar case with CAN_CTRLMODE_FD_NON_ISO we had on the M_CAN
> driver which only provides non-ISO configuration for the supported IP core
> and _no_ option to _change_ this value:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id
> =6cfda7fbebe8a4fd33ea5722fa0212f98f643c35
> 
> If you would do it similar in rcar_canfd.c with
> 
> /* CAN_CTRLMODE_FD is fixed with R-Car CAN FD */
> priv->can.ctrlmode = CAN_CTRLMODE_FD;
> 
> and remove CAN_CTRLMODE_FD from the priv->can.ctrlmode_supported
> assignment then it should do the entire configuration process correctly
> for you.
> Including the proper tests for the two bitrates.
> (see open_candev() in linux/drivers/net/can/dev.c)
> 
> Right?

I did try this option earlier but there are two problems with this method.

1) Below configuration is not possible

ip link set can0 up type can bitrate 100 dbitrate 100 fd on

"fd on" -> This is not allowed because CAN_CTRLMODE_FD bit is not set in 
ctrlmode_supported.

2) If I ignore "fd on", my interface MTU stays as CAN_MTU only. If I have to 
change the MTU alone to CANFD_MTU using another netlink message, it again 
checks ctrlmode_supported where it would fail. I have the option of providing 
my own change_mtu function & ignore this check but two configuration messages 
are required for my driver alone :-(.

Both these anomalies are addressed with the current check I have. 

Thanks,
Ramesh

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Tue, 08 Mar 2016 11:49:35 +0200
Jani Nikula  escreveu:

> On Tue, 08 Mar 2016, Dan Allen  wrote:
> > One of the key goals of the Asciidoctor project is to be able to directly
> > produce a wide variety of outputs from the same source (without DocBook).
> > We've added flexibility and best practices into the syntax and matured the
> > converter mechanism to bridge this (sometimes very wide) gap.  
> 
> I think our conclusion so far was that the native AsciiDoc (and
> Asciidoctor) outputs fell short of our needs, forcing us to use the
> DocBook pipeline. I, for one, was hoping we could eventually simplify
> the toolchain. For example, there was no support for chunked, or split
> to chapters, HTML, and the single page result was simply way too big.
> 
> > Asciidoctor is the future of AsciiDoc. Even the AsciiDoc Python maintainers
> > acknowledge that (including the original creator).  
> 
> Thanks for the input. We've touched the topic of AsciiDoc
> vs. Asciidoctor before [1]. So we should be using Asciidoctor instead of
> AsciiDoc. That actually makes choosing asciidoc harder, because
> requiring another language environment complicates, not simplifies, the
> toolchain. I'd really like to lower the bar for building the
> documentation, for everyone, so much so that it becomes part of the
> normal checks for patch inclusion.

As I failed to find a way to solve the issues with Sphinx/RST, I started
a PoC using Asciidoctor for the Media uAPI docbook conversion, in order
to see if this would work for us.

I'm not a big fan of using a language that I don't domain, like
Ruby (and the same applies to Python), but, as I said before,
provided that the toolchain works, can easily be installed on
Fedora and Debian, and provide the functionality I need, I'm
ok with that. 

On my tests, Asciidoctor is really fast. It takes a fraction of the
time require to build from DocBook, with is a good thing.

Yet, I suspect that it doesn't have the strict checks that xmllint
have. For example, I didn't see any warning about a missing cross-ref.
We use those warnings to discover if something is added at the code,
but were not documented. Its error reports are also crappy, as it
doesn't tell where the problem is. For example:

$ asciidoctor -n -b docbook media_api.adoc
asciidoctor: WARNING: tables must have at least one body row

On a document with 33793 lines (this is the size of the uAPI doc
when converted to AsciiDoc format), the above warning doesn't help.

So, I'm actually planning to use AsciiDoc/xmllint to check for
documentation troubles, if possible.

Even with AsciiDoc/Asciidoctor, there are several features at the
media documents that aren't well supported. For example, we widely
use the Docbook's tags to generate a manpage-like description:


  
V4L2 open()

  

  
v4l2-open
Open a V4L2 device
  

  

  #include fcntl.h
  
int open
const char *device_name
int flags
  

  

Asciidoctor doesn't produce anything like that, if the booktype is not
"manpage". Well, the media documentation is a multi-part book.

So, all those tags should be manually converted (actually, pandoc
made a mess with those tags - so manual work is required anyway,
no matter what markdown language we use). It will be a hard work,
but, at least, this is doable. 

Also, it doesn't accept images with PDF format. We have a few PDF
images, although I we have them also in GIF. So, not a big issue here.

I also did lots of table conversions, to see if our complex tables
would fit. The answer is: Yes: on all cases I converted, it worked
fine.

There are two ways of doing that:
- Nested tables
- Merging cells

Some tables we use won't work fine with nested tables, as they have
cells merging the entire line of such tables.

Also, converting some tables to nested tables would be incredible hard,
as we have really big tables there that would need to add dozens of nested
tables inside, like this one:


https://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#id-1.4.4.14.6.4

Using merging cells works fine, tough, and it is not hard to use.
The tables are easy to edit. The Asciidoctor syntax (not sure if AsciiDoc
also accepts this) is:

.MFC 5.1 Control IDs
[width="100%",cols="7%,40%,13%,40%",options="header",]
|===
|ID |Type 2+| Description

...

The "2+|" tells that the next content should be merged into two cells.

One of the good things is that we're not forced to use asciiart, with
would make it really hard to handle the tables.

For those wanting to see the results so far:

The html is at:

https://mchehab.fedorapeople.org/media-kabi-docs-test/asciidoc_tests/media_api.html

The testing tree is at:
https://git.linuxtv.org/mchehab/asciidoc-poc.git/

PS.: pandoc did a really crap job on the conversion. To convert this

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Tue, 08 Mar 2016, Dan Allen  wrote:
> One of the key goals of the Asciidoctor project is to be able to directly
> produce a wide variety of outputs from the same source (without DocBook).
> We've added flexibility and best practices into the syntax and matured the
> converter mechanism to bridge this (sometimes very wide) gap.

I think our conclusion so far was that the native AsciiDoc (and
Asciidoctor) outputs fell short of our needs, forcing us to use the
DocBook pipeline. I, for one, was hoping we could eventually simplify
the toolchain. For example, there was no support for chunked, or split
to chapters, HTML, and the single page result was simply way too big.

> Asciidoctor is the future of AsciiDoc. Even the AsciiDoc Python maintainers
> acknowledge that (including the original creator).

Thanks for the input. We've touched the topic of AsciiDoc
vs. Asciidoctor before [1]. So we should be using Asciidoctor instead of
AsciiDoc. That actually makes choosing asciidoc harder, because
requiring another language environment complicates, not simplifies, the
toolchain. I'd really like to lower the bar for building the
documentation, for everyone, so much so that it becomes part of the
normal checks for patch inclusion.


BR,
Jani.


[1] http://mid.gmane.org/86pow31ddj@hiro.keithp.com


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[James Morris]

On 03/08/2016 10:48 AM, James Morris wrote:

On 03/08/2016 06:54 AM, Andy Lutomirski wrote:


This makes sense, but I still think the design is poor.  If the hacker
gets code execution, then they can trivially brute force the ADI bits.



ADI in this scenario is intended to prevent the attacker from gaining
code execution in the first place.


Here's some more background from Enrico Perla (who literally wrote the 
book on kernel exploitation):


https://blogs.oracle.com/enrico/entry/hardening_allocators_with_adi

Probably the most significant advantage from a security point of view is 
the ability to eliminate an entire class of vulnerability: adjacent heap 
overflows, as discussed above, where, for example, adjacent heap objects 
are tagged differently.  Classic linear buffer overflows can be eliminated.


As Kees Cook outlined at the 2015 kernel summit, it's best to mitigate 
classes of vulnerabilities rather than patch each instance:


https://outflux.net/slides/2011/defcon/kernel-exploitation.pdf

The Linux ADI implementation is currently very rudimentary, and we 
definitely welcome continued feedback from the community and ideas as it 
evolves.


- James

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

[Ramesh Shanmugasundaram]

Hi Oliver,

Thanks for the comments.

> On 03/07/2016 09:32 AM, Ramesh Shanmugasundaram wrote:
> 
> > +   /* Ensure channel starts in FD mode */
> > +   if (!(priv->can.ctrlmode & CAN_CTRLMODE_FD)) {
> > +   netdev_err(ndev, "enable can fd mode for channel %d\n",
> ch);
> > +   goto fail_mode;
> > +   }
> 
>  What's the reason behind this check?
> 
>  A CAN FD capable CAN controller can be either configured to run as
>  CAN 2.0 (Classic CAN) or as CAN FD controller.
> 
>  So why are to throwing an error here and produce an initialization
>  failure?
> >>>
> >>> When this controller is configured in FD mode and used only with CAN
> >>> 2.0 nodes, it still expects a DTSEG (data bitrate) configuration
> >>> same as NTSEG (nominal bitrate). This check, specifically in
> >>> ndo_open, ensures both are configured and will work fine with CAN
> >>> 2.0 nodes
> >>> (e.g.)
> >>>
> >>> "ip link set can0 up type can bitrate 100 dbitrate 100 fd on"
> >>>
> >>> If I don't have this check, a configuration like this
> >>>
> >>> "ip link set can0 up type can bitrate 100"
> >>>
> >>> will bring up the controller without DTSEG configured.
> 
> What about spending some status flag or setting the data bitrate equal to
> the nominal bitrate unless a data bitrate is provided?

As you mentioned further down, when a user does this 

"ip link set can0 up type can bitrate 100"

the intention is to put the controller in CAN 2.0 mode. Even if we use a status 
flag or copy the data bitrate equal to the nominal bitrate, what would it 
achieve? It still cannot be a CAN 2.0 node - it is a CAN FD node configured 
with same nominal & data bitrate.

This is why I have this check in ndo_open, so that the user is aware it is a 
CAN FD node always and avoid misconfiguration like above with EOPNOTSUPP. 

> 
> >>
> >> That should bring up the controller in CAN 2.0 mode.
> >
> > Yes, that's the user's intention but the manual states DTSEG still need
> to be configured. In the above configuration, it will not be.
> > Besides, this will not be a "pure" CAN 2.0 node (i.e.) if a frame with
> length > 8 bytes is received the controller will "ACK" because in FD mode
> it can receive up to 64 bytes frame.
> 
> Oh. We probably mix something up here (CAN frame formats & bitrates).
> 
> A CAN2.0 frame and a CAN FD frame have very different representations on
> the wire! So if you see a FDF (former EDL) bit this is a CAN FD frame,
> which requires two bitrates (nominal/data bitrate) where the data bitrate
> has to be greater or equal the nominal bitrate.
> 
> The fact that the data bitrate is equal the nominal/arbitration bitrate
> has nothing to do with CAN2.0 then. Regarding your answer this is not even
> "a pure CAN2.0" node - it still looks like a CAN FD node with equal
> data/nominal bitrates.

I agree. May be I mixed up my wordings but my intention is same - the 
controller is still an FD node & not pure CAN 2.0 node. This is why I have the 
check.

> 
> The fact that a CAN FD frame has a size of 8 bytes doesn't make it a
> CAN2.0 frame :-)
> 
> >
> > The controller does support a "pure" classical CAN mode with a different
> set of register map itself.
> 
> Is this a can_rcar controller register mapping then?

Nope. This is a different IP compared to can_rcar. It has a different set of 
register map within the IP to act as a pure classical CAN 2.0 node. When I say 
"pure", it will pass CAN 2.0 conformance tests :-). It is worth adding this 
support? Do you think of a strong use case?
 
> 
> > Do you think a pure CAN 2.0 mode support would be beneficial? I can
> submit this in coming days on top of current submission.
> >
> > The current submission status is:
> >  - Controller operates in CAN FD mode only.
> >  - If needed to interoperate with CAN 2.0 nodes, data bitrate still need
> to be configured and it will work perfectly. However, it is not a "pure"
> CAN 2.0 node as mentioned above.
> 
> When you have a CAN FD /capable/ controller the idea is:
> 
> "ip link set can0 up type can bitrate 100"
> 
> The controller is in CAN2.0 mode:
> 
> 1. It can send and receive CAN2.0 frames @1MBit/s.
> 2. The MTU is set to 16 (sizeof(struct can_frame)) ; CAN_CTRLMODE_FD is
> unset.
> 3. The CAN controller is not CAN FD tolerant (will produce error frames)
> 
> "ip link set can0 up type can bitrate 100 dbitrate 100 fd on"
> 
> 1. It can send and receive CAN2.0 frames @1MBit/s.
> 2. It can send and receive CAN FD frames @1MBit/s (arbitration
> bitrate).
> 3. The MTU is set to 72 (sizeof(struct canfd_frame)) ; CAN_CTRLMODE_FD is
> set.
> 
> For CAN FD frames the data bitrate can be increased like:
> "ip link set can0 up type can bitrate 100 dbitrate 400 fd on"
> 
> So when CAN_CTRLMODE_FD is unset the controller should act like a "pure
> CAN2.0" node.

Yes & I am glad you clarified this expectation. I think we both agree on this. 
With my