* [PATCH] serial: atmel: fix incorrect baudrate setup
From: Tobias Schramm @ 2023-01-09 7:02 UTC (permalink / raw)
To: Richard Genoud
Cc: Greg Kroah-Hartman, Jiri Slaby, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, linux-serial, linux-kernel, Tobias Schramm
Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
setup") changed uart_set_options to select the correct baudrate
configuration based on the absolute error between requested baudrate and
available standard baudrate settings.
Prior to that commit the baudrate was selected based on which predefined
standard baudrate did not exceed the requested baudrate.
This change of selection logic was never reflected in the atmel serial
driver. Thus the comment left in the atmel serial driver is no longer
accurate.
Additionally the manual rounding up described in that comment and applied
via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
tty_termios_encode_baud_rate to determine the appropriate baudrate flags
this can cause baudrate selection to fail entirely because
tty_termios_encode_baud_rate will only select a baudrate if relative error
between requested and selected baudrate does not exceed +/-2%.
Fix that by requesting actual, exact baudrate used by the serial.
Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
---
drivers/tty/serial/atmel_serial.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index f1c06e12efa0..9cd7479b03c0 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2657,13 +2657,7 @@ static void __init atmel_console_get_options(struct uart_port *port, int *baud,
else if (mr == ATMEL_US_PAR_ODD)
*parity = 'o';
- /*
- * The serial core only rounds down when matching this to a
- * supported baud rate. Make sure we don't end up slightly
- * lower than one of those, as it would make us fall through
- * to a much lower baud rate than we really want.
- */
- *baud = port->uartclk / (16 * (quot - 1));
+ *baud = port->uartclk / (16 * quot);
}
static int __init atmel_console_setup(struct console *co, char *options)
--
2.30.2
^ permalink raw reply related
* Re: [PATCH] serial: atmel: fix incorrect baudrate setup
From: Tobias Schramm @ 2023-01-09 7:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Richard Genoud, Jiri Slaby, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, linux-serial, linux-kernel
In-Reply-To: <Y7u9SAX++YsXvnVC@kroah.com>
Am 09.01.23 um 08:07 schrieb Greg Kroah-Hartman:
> On Mon, Jan 09, 2023 at 08:02:00AM +0100, Tobias Schramm wrote:
>> Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
>> setup") changed uart_set_options to select the correct baudrate
>> configuration based on the absolute error between requested baudrate and
>> available standard baudrate settings.
>> Prior to that commit the baudrate was selected based on which predefined
>> standard baudrate did not exceed the requested baudrate.
>> This change of selection logic was never reflected in the atmel serial
>> driver. Thus the comment left in the atmel serial driver is no longer
>> accurate.
>> Additionally the manual rounding up described in that comment and applied
>> via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
>> tty_termios_encode_baud_rate to determine the appropriate baudrate flags
>> this can cause baudrate selection to fail entirely because
>> tty_termios_encode_baud_rate will only select a baudrate if relative error
>> between requested and selected baudrate does not exceed +/-2%.
>> Fix that by requesting actual, exact baudrate used by the serial.
>>
>> Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
>> ---
> What commit id does this fix? Please list that as a the "Fixes:" tag.
Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
setup") is the one that breaks the assumptions made in the driver.
I'll send a v2 and include that.
>
> Also, does this need to go to older/stable kernels?
Yep, this should go to older kernels as a fix, too.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH v2] serial: atmel: fix incorrect baudrate setup
From: Tobias Schramm @ 2023-01-09 7:29 UTC (permalink / raw)
To: Richard Genoud, Greg Kroah-Hartman
Cc: Jiri Slaby, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-serial, linux-kernel, Tobias Schramm
Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
setup") changed uart_set_options to select the correct baudrate
configuration based on the absolute error between requested baudrate and
available standard baudrate settings.
Prior to that commit the baudrate was selected based on which predefined
standard baudrate did not exceed the requested baudrate.
This change of selection logic was never reflected in the atmel serial
driver. Thus the comment left in the atmel serial driver is no longer
accurate.
Additionally the manual rounding up described in that comment and applied
via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
tty_termios_encode_baud_rate to determine the appropriate baudrate flags
this can cause baudrate selection to fail entirely because
tty_termios_encode_baud_rate will only select a baudrate if relative error
between requested and selected baudrate does not exceed +/-2%.
Fix that by requesting actual, exact baudrate used by the serial.
Fixes: ba47f97a18f2 ("serial: core: remove baud_rates when serial console setup")
Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
---
drivers/tty/serial/atmel_serial.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index f1c06e12efa0..9cd7479b03c0 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2657,13 +2657,7 @@ static void __init atmel_console_get_options(struct uart_port *port, int *baud,
else if (mr == ATMEL_US_PAR_ODD)
*parity = 'o';
- /*
- * The serial core only rounds down when matching this to a
- * supported baud rate. Make sure we don't end up slightly
- * lower than one of those, as it would make us fall through
- * to a much lower baud rate than we really want.
- */
- *baud = port->uartclk / (16 * (quot - 1));
+ *baud = port->uartclk / (16 * quot);
}
static int __init atmel_console_setup(struct console *co, char *options)
--
2.30.2
^ permalink raw reply related
* Re: [niks:has_ioport_v3] [tty] aa0652d7f1: BUG:kernel_NULL_pointer_dereference,address
From: Niklas Schnelle @ 2023-01-09 8:45 UTC (permalink / raw)
To: Arnd Bergmann, kernel test robot
Cc: oe-lkp, kernel test robot, linux-kernel, linux-serial
In-Reply-To: <e211f932-77c3-427a-859a-d846598524ed@app.fastmail.com>
On Thu, 2023-01-05 at 09:03 +0100, Arnd Bergmann wrote:
> On Thu, Jan 5, 2023, at 06:54, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed BUG:kernel_NULL_pointer_dereference,address due to
> > commit (built with clang-14):
> >
> > commit: aa0652d7f1b311e55232a8153522fdaaba0f197a ("tty: serial: handle
> > HAS_IOPORT dependencies")
> > https://git.kernel.org/cgit/linux/kernel/git/niks/linux.git
> > has_ioport_v3
> >
> > in testcase: boot
> >
> > on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire
> > log/backtrace):
> >
> >
> > [ 2.166733][ T0] calling univ8250_console_init+0x0/0x30 @ 0
> > [ 2.167555][ T0] BUG: kernel NULL pointer dereference, address:
> > 00000000
>
> I think it's this bit:
>
> @@ -508,12 +523,13 @@ static void set_io_from_upio(struct uart_port *p)
> up->dl_read = au_serial_dl_read;
> up->dl_write = au_serial_dl_write;
> break;
> -#endif
> -
> +#ifdef CONFIG_HAS_IOPORT
> default:
> p->serial_in = io_serial_in;
> p->serial_out = io_serial_out;
> break;
> +#endif
> +#endif
> }
> /* Remember loaded iotype */
> up->cur_iotype = p->iotype;
>
>
> which puts the 'default' case inside of '#ifdef
> CONFIG_SERIAL_8250_RT288X'. x86 does not use the
> RT288x variant but relies on the default, so any
> call to io_serial_{in,out} will cause a NULL
> pointer dereference.
>
> Arnd
Thanks for looking into it Arnd, your reasoning makes sense to me, I'll
try to look into this and test this case before I sent out the v3 of
the HAS_IOPORT patches. I still also have a few nitpicks from Bjorn,
mostly about the commit messages, to work in. Hope to do that soon but
got a few things going on at the moment.
^ permalink raw reply
* Re: [PATCH v3] serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler
From: Sebastian Andrzej Siewior @ 2023-01-09 10:13 UTC (permalink / raw)
To: Johan Hovold
Cc: Marek Vasut, linux-serial, Alexandre Torgue, Erwan Le Ray,
Greg Kroah-Hartman, Jiri Slaby, Maxime Coquelin, Thomas Gleixner,
Valentin Caron, linux-arm-kernel, linux-stm32
In-Reply-To: <Y6sHr5kuxUoahlzJ@hovoldconsulting.com>
On 2022-12-27 15:56:47 [+0100], Johan Hovold wrote:
> On Fri, Dec 16, 2022 at 12:53:38PM +0100, Marek Vasut wrote:
> > Requesting an interrupt with IRQF_ONESHOT will run the primary handler
> > in the hard-IRQ context even in the force-threaded mode. The
> > force-threaded mode is used by PREEMPT_RT in order to avoid acquiring
> > sleeping locks (spinlock_t) in hard-IRQ context. This combination
> > makes it impossible and leads to "sleeping while atomic" warnings.
> >
> > Use one interrupt handler for both handlers (primary and secondary)
> > and drop the IRQF_ONESHOT flag which is not needed.
> >
> > Fixes: e359b4411c283 ("serial: stm32: fix threaded interrupt handling")
>
> I don't think a Fixes tag is warranted as this is only needed due to
> this undocumented quirk of PREEMPT_RT.
It is not an undocumented quirk of PREEMPT_RT. The part that might not
be well documented is that IRQF_ONESHOT won't run the primary handler as
a threaded handler. This is also the case for IRQF_NO_THREAD and
IRQF_PERCPU but might be more obvious.
Anyway, if the primary handler is not threaded then it runs in HARDIRQ
context and here you must not use a spinlock_t. This is documented in
Documentation/locking/locktypes.rst and there is also a LOCKDEP warning
for this on !RT which is off by default because it triggers with printk
(and this is worked on).
> And this should not be backported in any case.
Such things have been backported via -stable in the past. If you
disagree, please keep me in loop while is merged so I can poke people to
backport it as part of the RT patch for the relevant kernels.
> Johan
Sebastian
^ permalink raw reply
* Re: [PATCH v9 1/4] Documentation: fpga: dfl: Add documentation for DFHv1
From: Tom Rix @ 2023-01-09 13:48 UTC (permalink / raw)
To: matthew.gerlach, hao.wu, yilun.xu, russell.h.weight,
basheer.ahmed.muddebihal, mdf, linux-fpga, linux-doc,
linux-kernel, tianfei.zhang, corbet, gregkh, linux-serial,
jirislaby, geert+renesas, andriy.shevchenko,
niklas.soderlund+renesas, macro, johan, lukas, ilpo.jarvinen,
marpagan, bagasdotme
In-Reply-To: <20230104232253.24743-2-matthew.gerlach@linux.intel.com>
On 1/4/23 3:22 PM, matthew.gerlach@linux.intel.com wrote:
> From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
>
> Add documentation describing the extensions provided by Version
> 1 of the Device Feature Header (DFHv1).
>
> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Thanks for the changes.
Reviewed-by: Tom Rix <trix@redhat.com>
> ---
> v9: move DFH definitions to after the Overview
> fix name of feature revision field
> clarify next field in DFH
>
> v8: fix section titles
>
> v7: shorten long lines and wording suggestions by bagasdotme@gmail.com
>
> v6: no change
>
> v5: use nested list for field descriptions
> clean up prose
> add reviewed-by and comments from Ilpo Järvinen
>
> v4: Remove marketing speak and separate v0 and v1 descriptions.
> Fix errors reported by "make htmldocs".
>
> v3: no change
>
> v2: s/GUILD/GUID/
> add picture
> ---
> Documentation/fpga/dfl.rst | 117 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 117 insertions(+)
>
> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> index 15b670926084..7e015249785b 100644
> --- a/Documentation/fpga/dfl.rst
> +++ b/Documentation/fpga/dfl.rst
> @@ -75,6 +75,123 @@ convenient for software to locate each feature by walking through this list,
> and can be implemented in register regions of any FPGA device.
>
>
> +Device Feature Header - Version 0
> +=================================
> +Version 0 (DFHv0) is the original version of the Device Feature Header.
> +The format of DFHv0 is shown below::
> +
> + +-----------------------------------------------------------------------+
> + |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID 0| 0x00
> + +-----------------------------------------------------------------------+
> + |63 GUID_L 0| 0x08
> + +-----------------------------------------------------------------------+
> + |63 GUID_H 0| 0x10
> + +-----------------------------------------------------------------------+
> +
> +- Offset 0x00
> +
> + * Type - The type of DFH (e.g. FME, AFU, or private feature).
> + * DFH VER - The version of the DFH.
> + * Rsvd - Currently unused.
> + * EOL - Set if the DFH is the end of the Device Feature List (DFL).
> + * Next - The offset in bytes of the next DFH in the DFL from the DFH start,
> + and the start of a DFH must be aligned to an 8 byte boundary.
> + If EOL is set, Next is the size of MMIO of the last feature in the list.
> + * REV - The revision of the feature associated with this header.
> + * ID - The feature ID if Type is private feature.
> +
> +- Offset 0x08
> +
> + * GUID_L - Least significant 64 bits of a 128-bit Globally Unique Identifier
> + (present only if Type is FME or AFU).
> +
> +- Offset 0x10
> +
> + * GUID_H - Most significant 64 bits of a 128-bit Globally Unique Identifier
> + (present only if Type is FME or AFU).
> +
> +
> +Device Feature Header - Version 1
> +=================================
> +Version 1 (DFHv1) of the Device Feature Header adds the following functionality:
> +
> +* Provides a standardized mechanism for features to describe
> + parameters/capabilities to software.
> +* Standardize the use of a GUID for all DFHv1 types.
> +* Decouples the DFH location from the register space of the feature itself.
> +
> +The format of Version 1 of the Device Feature Header (DFH) is shown below::
> +
> + +-----------------------------------------------------------------------+
> + |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID 0| 0x00
> + +-----------------------------------------------------------------------+
> + |63 GUID_L 0| 0x08
> + +-----------------------------------------------------------------------+
> + |63 GUID_H 0| 0x10
> + +-----------------------------------------------------------------------+
> + |63 Reg Address/Offset 1| Rel 0| 0x18
> + +-----------------------------------------------------------------------+
> + |63 Reg Size 32|Params 31|30 Group 16|15 Instance 0| 0x20
> + +-----------------------------------------------------------------------+
> + |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID 0| 0x28
> + +-----------------------------------------------------------------------+
> + |63 Parameter Data 0| 0x30
> + +-----------------------------------------------------------------------+
> +
> + ...
> +
> + +-----------------------------------------------------------------------+
> + |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID 0|
> + +-----------------------------------------------------------------------+
> + |63 Parameter Data 0|
> + +-----------------------------------------------------------------------+
> +
> +- Offset 0x00
> +
> + * Type - The type of DFH (e.g. FME, AFU, or private feature).
> + * DFH VER - The version of the DFH.
> + * Rsvd - Currently unused.
> + * EOL - Set if the DFH is the end of the Device Feature List (DFL).
> + * Next - The offset in bytes of the next DFH in the DFL from the DFH start,
> + and the start of a DFH must be aligned to an 8 byte boundary.
> + If EOL is set, Next is the size of MMIO of the last feature in the list.
> + * REV - The revision of the feature associated with this header.
> + * ID - The feature ID if Type is private feature.
> +
> +- Offset 0x08
> +
> + * GUID_L - Least significant 64 bits of a 128-bit Globally Unique Identifier.
> +
> +- Offset 0x10
> +
> + * GUID_H - Most significant 64 bits of a 128-bit Globally Unique Identifier.
> +
> +- Offset 0x18
> +
> + * Reg Address/Offset - If Rel bit is set, then the value is the high 63 bits
> + of a 16-bit aligned absolute address of the feature's registers. Otherwise
> + the value is the offset from the start of the DFH of the feature's registers.
> +
> +- Offset 0x20
> +
> + * Reg Size - Size of feature's register set in bytes.
> + * Params - Set if DFH has a list of parameter blocks.
> + * Group - Id of group if feature is part of a group.
> + * Instance - Id of feature instance within a group.
> +
> +- Offset 0x28 if feature has parameters
> +
> + * Next - Offset to the next parameter block in 8 byte words. If EOP set,
> + size in 8 byte words of last parameter.
> + * Param Version - Version of Param ID.
> + * Param ID - ID of parameter.
> +
> +- Offset 0x30
> +
> + * Parameter Data - Parameter data whose size and format is defined by
> + version and ID of the parameter.
> +
> +
> FIU - FME (FPGA Management Engine)
> ==================================
> The FPGA Management Engine performs reconfiguration and other infrastructure
^ permalink raw reply
* [PATCH] serial: msm: add lock annotation to msm_set_baud_rate()
From: Krzysztof Kozlowski @ 2023-01-09 15:22 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Greg Kroah-Hartman,
Jiri Slaby, linux-arm-msm, linux-serial, linux-kernel
Cc: Krzysztof Kozlowski
msm_set_baud_rate() releases and re-acquires the port->lock, thus add
lock annotation for Sparse static code checks.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/tty/serial/msm_serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 7dd19a281579..44e1e83127ac 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -1125,6 +1125,7 @@ msm_find_best_baud(struct uart_port *port, unsigned int baud,
static int msm_set_baud_rate(struct uart_port *port, unsigned int baud,
unsigned long *saved_flags)
+ __must_hold(&port->lock)
{
unsigned int rxstale, watermark, mask;
struct msm_port *msm_port = to_msm_port(port);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v9 1/4] Documentation: fpga: dfl: Add documentation for DFHv1
From: matthew.gerlach @ 2023-01-09 16:40 UTC (permalink / raw)
To: Tom Rix
Cc: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal, mdf,
linux-fpga, linux-doc, linux-kernel, tianfei.zhang, corbet,
gregkh, linux-serial, jirislaby, geert+renesas, andriy.shevchenko,
niklas.soderlund+renesas, macro, johan, lukas, ilpo.jarvinen,
marpagan, bagasdotme
In-Reply-To: <4e7f84ff-8bab-019d-3858-4c545834a354@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 7401 bytes --]
On Mon, 9 Jan 2023, Tom Rix wrote:
>
> On 1/4/23 3:22 PM, matthew.gerlach@linux.intel.com wrote:
>> From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
>>
>> Add documentation describing the extensions provided by Version
>> 1 of the Device Feature Header (DFHv1).
>>
>> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
>> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>
> Thanks for the changes.
>
> Reviewed-by: Tom Rix <trix@redhat.com>
Thanks for the review,
Matthew Gerlach
>
>> ---
>> v9: move DFH definitions to after the Overview
>> fix name of feature revision field
>> clarify next field in DFH
>>
>> v8: fix section titles
>>
>> v7: shorten long lines and wording suggestions by bagasdotme@gmail.com
>>
>> v6: no change
>>
>> v5: use nested list for field descriptions
>> clean up prose
>> add reviewed-by and comments from Ilpo Järvinen
>>
>> v4: Remove marketing speak and separate v0 and v1 descriptions.
>> Fix errors reported by "make htmldocs".
>>
>> v3: no change
>>
>> v2: s/GUILD/GUID/
>> add picture
>> ---
>> Documentation/fpga/dfl.rst | 117 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 117 insertions(+)
>>
>> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
>> index 15b670926084..7e015249785b 100644
>> --- a/Documentation/fpga/dfl.rst
>> +++ b/Documentation/fpga/dfl.rst
>> @@ -75,6 +75,123 @@ convenient for software to locate each feature by
>> walking through this list,
>> and can be implemented in register regions of any FPGA device.
>> +Device Feature Header - Version 0
>> +=================================
>> +Version 0 (DFHv0) is the original version of the Device Feature Header.
>> +The format of DFHv0 is shown below::
>> +
>> +
>> +-----------------------------------------------------------------------+
>> + |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID
>> 0| 0x00
>> +
>> +-----------------------------------------------------------------------+
>> + |63 GUID_L
>> 0| 0x08
>> +
>> +-----------------------------------------------------------------------+
>> + |63 GUID_H
>> 0| 0x10
>> +
>> +-----------------------------------------------------------------------+
>> +
>> +- Offset 0x00
>> +
>> + * Type - The type of DFH (e.g. FME, AFU, or private feature).
>> + * DFH VER - The version of the DFH.
>> + * Rsvd - Currently unused.
>> + * EOL - Set if the DFH is the end of the Device Feature List (DFL).
>> + * Next - The offset in bytes of the next DFH in the DFL from the DFH
>> start,
>> + and the start of a DFH must be aligned to an 8 byte boundary.
>> + If EOL is set, Next is the size of MMIO of the last feature in the
>> list.
>> + * REV - The revision of the feature associated with this header.
>> + * ID - The feature ID if Type is private feature.
>> +
>> +- Offset 0x08
>> +
>> + * GUID_L - Least significant 64 bits of a 128-bit Globally Unique
>> Identifier
>> + (present only if Type is FME or AFU).
>> +
>> +- Offset 0x10
>> +
>> + * GUID_H - Most significant 64 bits of a 128-bit Globally Unique
>> Identifier
>> + (present only if Type is FME or AFU).
>> +
>> +
>> +Device Feature Header - Version 1
>> +=================================
>> +Version 1 (DFHv1) of the Device Feature Header adds the following
>> functionality:
>> +
>> +* Provides a standardized mechanism for features to describe
>> + parameters/capabilities to software.
>> +* Standardize the use of a GUID for all DFHv1 types.
>> +* Decouples the DFH location from the register space of the feature
>> itself.
>> +
>> +The format of Version 1 of the Device Feature Header (DFH) is shown
>> below::
>> +
>> +
>> +-----------------------------------------------------------------------+
>> + |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID
>> 0| 0x00
>> +
>> +-----------------------------------------------------------------------+
>> + |63 GUID_L
>> 0| 0x08
>> +
>> +-----------------------------------------------------------------------+
>> + |63 GUID_H
>> 0| 0x10
>> +
>> +-----------------------------------------------------------------------+
>> + |63 Reg Address/Offset 1| Rel
>> 0| 0x18
>> +
>> +-----------------------------------------------------------------------+
>> + |63 Reg Size 32|Params 31|30 Group 16|15 Instance
>> 0| 0x20
>> +
>> +-----------------------------------------------------------------------+
>> + |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID
>> 0| 0x28
>> +
>> +-----------------------------------------------------------------------+
>> + |63 Parameter Data
>> 0| 0x30
>> +
>> +-----------------------------------------------------------------------+
>> +
>> + ...
>> +
>> +
>> +-----------------------------------------------------------------------+
>> + |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID
>> 0|
>> +
>> +-----------------------------------------------------------------------+
>> + |63 Parameter Data
>> 0|
>> +
>> +-----------------------------------------------------------------------+
>> +
>> +- Offset 0x00
>> +
>> + * Type - The type of DFH (e.g. FME, AFU, or private feature).
>> + * DFH VER - The version of the DFH.
>> + * Rsvd - Currently unused.
>> + * EOL - Set if the DFH is the end of the Device Feature List (DFL).
>> + * Next - The offset in bytes of the next DFH in the DFL from the DFH
>> start,
>> + and the start of a DFH must be aligned to an 8 byte boundary.
>> + If EOL is set, Next is the size of MMIO of the last feature in the
>> list.
>> + * REV - The revision of the feature associated with this header.
>> + * ID - The feature ID if Type is private feature.
>> +
>> +- Offset 0x08
>> +
>> + * GUID_L - Least significant 64 bits of a 128-bit Globally Unique
>> Identifier.
>> +
>> +- Offset 0x10
>> +
>> + * GUID_H - Most significant 64 bits of a 128-bit Globally Unique
>> Identifier.
>> +
>> +- Offset 0x18
>> +
>> + * Reg Address/Offset - If Rel bit is set, then the value is the high 63
>> bits
>> + of a 16-bit aligned absolute address of the feature's registers.
>> Otherwise
>> + the value is the offset from the start of the DFH of the feature's
>> registers.
>> +
>> +- Offset 0x20
>> +
>> + * Reg Size - Size of feature's register set in bytes.
>> + * Params - Set if DFH has a list of parameter blocks.
>> + * Group - Id of group if feature is part of a group.
>> + * Instance - Id of feature instance within a group.
>> +
>> +- Offset 0x28 if feature has parameters
>> +
>> + * Next - Offset to the next parameter block in 8 byte words. If EOP set,
>> + size in 8 byte words of last parameter.
>> + * Param Version - Version of Param ID.
>> + * Param ID - ID of parameter.
>> +
>> +- Offset 0x30
>> +
>> + * Parameter Data - Parameter data whose size and format is defined by
>> + version and ID of the parameter.
>> +
>> +
>> FIU - FME (FPGA Management Engine)
>> ==================================
>> The FPGA Management Engine performs reconfiguration and other
>> infrastructure
>
>
^ permalink raw reply
* Re: [PATCH v9 3/4] fpga: dfl: add basic support for DFHv1
From: matthew.gerlach @ 2023-01-09 18:04 UTC (permalink / raw)
To: Xu Yilun
Cc: hao.wu, russell.h.weight, basheer.ahmed.muddebihal, trix, mdf,
linux-fpga, linux-doc, linux-kernel, tianfei.zhang, corbet,
gregkh, linux-serial, jirislaby, geert+renesas, andriy.shevchenko,
niklas.soderlund+renesas, macro, johan, lukas, ilpo.jarvinen,
marpagan, bagasdotme
In-Reply-To: <Y7u31S8aba1L+VeA@yilunxu-OptiPlex-7050>
[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]
On Mon, 9 Jan 2023, Xu Yilun wrote:
> On 2023-01-04 at 15:22:52 -0800, matthew.gerlach@linux.intel.com wrote:
>> From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
>>
>> Version 1 of the Device Feature Header (DFH) definition adds
>> functionality to the Device Feature List (DFL) bus.
>>
>> A DFHv1 header may have one or more parameter blocks that
>> further describes the HW to SW. Add support to the DFL bus
>> to parse the MSI-X parameter.
>>
>> The location of a feature's register set is explicitly
>> described in DFHv1 and can be relative to the base of the DFHv1
>> or an absolute address. Parse the location and pass the information
>> to DFL driver.
>>
>> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
>> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>>
>
> [...]
>
>> +static u64 *find_param(u64 *params, resource_size_t max, int param_id)
>> +{
>> + u64 *end = params + max / sizeof(u64);
>> + u64 v, next;
>> +
>> + while (params < end) {
>> + v = *params;
>> + if (param_id == FIELD_GET(DFHv1_PARAM_HDR_ID, v))
>> + return params;
>> +
>> + if (FIELD_GET(DFHv1_PARAM_HDR_NEXT_EOP, v))
>> + break;
>> +
>> + next = FIELD_GET(DFHv1_PARAM_HDR_NEXT_OFFSET, v);
>> + params += next;
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +/**
>> + * dfh_find_param() - find parameter block for the given parameter id
>> + * @dfl_dev: dfl device
>> + * @param_id: id of dfl parameter
>> + * @pcount: destination to store size of parameter data in u64 bit words
>
> As I mentioned before, could the size of the parameter data just be number
> of bytes? This is the most common way for a data block.
returning a void* and a size_t in bytes would be more consistent. I will
make your suggested change.
Thanks,
Matthew Gerlach
>
> Thanks,
> Yilun
>
>> + *
>> + * Return: pointer to start of parameter data, PTR_ERR otherwise.
>> + */
>> +void *dfh_find_param(struct dfl_device *dfl_dev, int param_id, size_t *pcount)
>> +{
>> + u64 *phdr = find_param(dfl_dev->params, dfl_dev->param_size, param_id);
>> +
>> + if (!phdr)
>> + return ERR_PTR(-ENOENT);
>> +
>> + if (pcount)
>> + *pcount = FIELD_GET(DFHv1_PARAM_HDR_NEXT_OFFSET, *phdr) - 1;
>> +
>> + return phdr + 1;
>> +}
>> +EXPORT_SYMBOL_GPL(dfh_find_param);
>
^ permalink raw reply
* Re: [PATCH v3] serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler
From: Marek Vasut @ 2023-01-09 19:19 UTC (permalink / raw)
To: Johan Hovold
Cc: linux-serial, Sebastian Andrzej Siewior, Alexandre Torgue,
Erwan Le Ray, Greg Kroah-Hartman, Jiri Slaby, Maxime Coquelin,
Thomas Gleixner, Valentin Caron, linux-arm-kernel, linux-stm32
In-Reply-To: <Y7f+birb2KpTygxI@hovoldconsulting.com>
On 1/6/23 11:56, Johan Hovold wrote:
> On Thu, Jan 05, 2023 at 09:46:57PM +0100, Marek Vasut wrote:
>> On 12/27/22 15:56, Johan Hovold wrote:
>>
>> [...]
>>
>>>> @@ -793,27 +794,13 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
>>>> }
>>>>
>>>> if ((sr & USART_SR_TXE) && !(stm32_port->tx_ch)) {
>>>> - spin_lock(&port->lock);
>>>> + spin_lock_irqsave(&port->lock, flags);
>>>> stm32_usart_transmit_chars(port);
>>>> - spin_unlock(&port->lock);
>>>> + spin_unlock_irqrestore(&port->lock, flags);
>>>
>>> This is not needed as the handler runs with interrupts disabled.
>>
>> On SMP system, another thread on another core can call
>> stm32_usart_transmit_chars() . I don't think removing the locking is
>> correct ?
>
> I didn't say that you should remove the locking, which is very much
> needed. There's just no need to disable interrupts in a (non-threaded)
> interrupt handler as that has already been done by IRQ core (and, yes,
> that is also the case with forced threading).
Ah, understood.
^ permalink raw reply
* [PATCH v10 0/4] Enhance definition of DFH and use enhancements for UART driver
From: matthew.gerlach @ 2023-01-10 0:30 UTC (permalink / raw)
To: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal,
trix, mdf, linux-fpga, linux-doc, linux-kernel, tianfei.zhang,
corbet, gregkh, linux-serial, jirislaby, geert+renesas,
andriy.shevchenko, niklas.soderlund+renesas, macro, johan, lukas,
ilpo.jarvinen, marpagan, bagasdotme
Cc: Matthew Gerlach
From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
This patchset enhances the definition of the Device Feature Header (DFH) used by
the Device Feature List (DFL) bus and then uses the new enhancements in a UART
driver.
The enhancements to the DFH includes the introduction of parameter blocks.
Like PCI capabilities, the DFH parameter blocks further describe
the hardware to software. In the case of the UART, the parameter blocks
provide information for the interrupt, clock frequency, and register layout.
Duplication of code parsing of the parameter blocks in multiple DFL drivers
is a concern. Using swnodes was considered to help minimize parsing code
duplication, but their use did not help the problem. Furthermore the highly
changeable nature of FPGAs employing the DFL bus makes the use of swnodes
inappropriate.
Patch 1 updates the DFL documentation to describe the added functionality to DFH.
Patch 2 adds the definitions for DFHv1.
Patch 3 adds basic support for DFHv1. It adds functionality to parse parameter blocks
and adds the functionality to parse the explicit location of a feature's register set.
Patch 4 adds a DFL UART driver that makes use of the new features of DFHv1.
Basheer Ahmed Muddebihal (1):
fpga: dfl: Add DFHv1 Register Definitions
Matthew Gerlach (3):
Documentation: fpga: dfl: Add documentation for DFHv1
fpga: dfl: add basic support for DFHv1
tty: serial: 8250: add DFL bus driver for Altera 16550.
Documentation/fpga/dfl.rst | 117 ++++++++++++++
drivers/fpga/dfl.c | 245 +++++++++++++++++++++++------
drivers/fpga/dfl.h | 43 +++++
drivers/tty/serial/8250/8250_dfl.c | 167 ++++++++++++++++++++
drivers/tty/serial/8250/Kconfig | 12 ++
drivers/tty/serial/8250/Makefile | 1 +
include/linux/dfl.h | 8 +
7 files changed, 542 insertions(+), 51 deletions(-)
create mode 100644 drivers/tty/serial/8250/8250_dfl.c
--
2.25.1
^ permalink raw reply
* [PATCH v10 2/4] fpga: dfl: Add DFHv1 Register Definitions
From: matthew.gerlach @ 2023-01-10 0:30 UTC (permalink / raw)
To: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal,
trix, mdf, linux-fpga, linux-doc, linux-kernel, tianfei.zhang,
corbet, gregkh, linux-serial, jirislaby, geert+renesas,
andriy.shevchenko, niklas.soderlund+renesas, macro, johan, lukas,
ilpo.jarvinen, marpagan, bagasdotme
Cc: Basheer Ahmed Muddebihal, Matthew Gerlach
In-Reply-To: <20230110003029.806022-1-matthew.gerlach@linux.intel.com>
From: Basheer Ahmed Muddebihal <basheer.ahmed.muddebihal@linux.intel.com>
This patch adds the definitions for DFHv1 header and related register
bitfields.
Signed-off-by: Basheer Ahmed Muddebihal <basheer.ahmed.muddebihal@linux.intel.com>
Co-developed-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
v10: no change
v9: no change
v8: add Rb Andy Shevchenko
v7: no change
v6: remove parameter definitions from include/linux/dfl.h
v5: consistently use fields for parameter data
s/EOL/EOP/ to match doc
remove unneeded mask
added Co-developed-by
v4: s/MSIX/MSI_X/g
move kerneldoc to implementation
don't change copyright date
v3:
keep DFHv1 definitions "hidden" in drivers/fpga/dfl.h
v2: clean up white space and one line comments
remove extra space in commit
use uniform number of digits in constants
don't change copyright date because of removed content
---
drivers/fpga/dfl.h | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index 06cfcd5e84bb..fc59f33367ee 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -74,11 +74,43 @@
#define DFH_REVISION GENMASK_ULL(15, 12) /* Feature revision */
#define DFH_NEXT_HDR_OFST GENMASK_ULL(39, 16) /* Offset to next DFH */
#define DFH_EOL BIT_ULL(40) /* End of list */
+#define DFH_VERSION GENMASK_ULL(59, 52) /* DFH version */
#define DFH_TYPE GENMASK_ULL(63, 60) /* Feature type */
#define DFH_TYPE_AFU 1
#define DFH_TYPE_PRIVATE 3
#define DFH_TYPE_FIU 4
+/*
+ * DFHv1 Register Offset definitons
+ * In DHFv1, DFH + GUID + CSR_START + CSR_SIZE_GROUP + PARAM_HDR + PARAM_DATA
+ * as common header registers
+ */
+#define DFHv1_CSR_ADDR 0x18 /* CSR Register start address */
+#define DFHv1_CSR_SIZE_GRP 0x20 /* Size of Reg Block and Group/tag */
+#define DFHv1_PARAM_HDR 0x28 /* Optional First Param header */
+
+/*
+ * CSR Rel Bit, 1'b0 = relative (offset from feature DFH start),
+ * 1'b1 = absolute (ARM or other non-PCIe use)
+ */
+#define DFHv1_CSR_ADDR_REL BIT_ULL(0)
+
+/* CSR Header Register Bit Definitions */
+#define DFHv1_CSR_ADDR_MASK GENMASK_ULL(63, 1) /* 63:1 of CSR address */
+
+/* CSR SIZE Goup Register Bit Definitions */
+#define DFHv1_CSR_SIZE_GRP_INSTANCE_ID GENMASK_ULL(15, 0) /* Enumeration instantiated IP */
+#define DFHv1_CSR_SIZE_GRP_GROUPING_ID GENMASK_ULL(30, 16) /* Group Features/interfaces */
+#define DFHv1_CSR_SIZE_GRP_HAS_PARAMS BIT_ULL(31) /* Presence of Parameters */
+#define DFHv1_CSR_SIZE_GRP_SIZE GENMASK_ULL(63, 32) /* Size of CSR Block in bytes */
+
+/* PARAM Header Register Bit Definitions */
+#define DFHv1_PARAM_HDR_ID GENMASK_ULL(15, 0) /* Id of this Param */
+#define DFHv1_PARAM_HDR_VER GENMASK_ULL(31, 16) /* Version Param */
+#define DFHv1_PARAM_HDR_NEXT_OFFSET GENMASK_ULL(63, 35) /* Offset of next Param */
+#define DFHv1_PARAM_HDR_NEXT_EOP BIT_ULL(32)
+#define DFHv1_PARAM_DATA 0x08 /* Offset of Param data from Param header */
+
/* Next AFU Register Bitfield */
#define NEXT_AFU_NEXT_DFH_OFST GENMASK_ULL(23, 0) /* Offset to next AFU */
--
2.25.1
^ permalink raw reply related
* [PATCH v10 1/4] Documentation: fpga: dfl: Add documentation for DFHv1
From: matthew.gerlach @ 2023-01-10 0:30 UTC (permalink / raw)
To: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal,
trix, mdf, linux-fpga, linux-doc, linux-kernel, tianfei.zhang,
corbet, gregkh, linux-serial, jirislaby, geert+renesas,
andriy.shevchenko, niklas.soderlund+renesas, macro, johan, lukas,
ilpo.jarvinen, marpagan, bagasdotme
Cc: Matthew Gerlach
In-Reply-To: <20230110003029.806022-1-matthew.gerlach@linux.intel.com>
From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Add documentation describing the extensions provided by Version
1 of the Device Feature Header (DFHv1).
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Tom Rix <trix@redhat.com>
---
v10: ad Rb Tom Rix
v9: move DFH definitions to after the Overview
fix name of feature revision field
clarify next field in DFH
v8: fix section titles
v7: shorten long lines and wording suggestions by bagasdotme@gmail.com
v6: no change
v5: use nested list for field descriptions
clean up prose
add reviewed-by and comments from Ilpo Järvinen
v4: Remove marketing speak and separate v0 and v1 descriptions.
Fix errors reported by "make htmldocs".
v3: no change
v2: s/GUILD/GUID/
add picture
---
Documentation/fpga/dfl.rst | 117 +++++++++++++++++++++++++++++++++++++
1 file changed, 117 insertions(+)
diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index 15b670926084..7e015249785b 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -75,6 +75,123 @@ convenient for software to locate each feature by walking through this list,
and can be implemented in register regions of any FPGA device.
+Device Feature Header - Version 0
+=================================
+Version 0 (DFHv0) is the original version of the Device Feature Header.
+The format of DFHv0 is shown below::
+
+ +-----------------------------------------------------------------------+
+ |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID 0| 0x00
+ +-----------------------------------------------------------------------+
+ |63 GUID_L 0| 0x08
+ +-----------------------------------------------------------------------+
+ |63 GUID_H 0| 0x10
+ +-----------------------------------------------------------------------+
+
+- Offset 0x00
+
+ * Type - The type of DFH (e.g. FME, AFU, or private feature).
+ * DFH VER - The version of the DFH.
+ * Rsvd - Currently unused.
+ * EOL - Set if the DFH is the end of the Device Feature List (DFL).
+ * Next - The offset in bytes of the next DFH in the DFL from the DFH start,
+ and the start of a DFH must be aligned to an 8 byte boundary.
+ If EOL is set, Next is the size of MMIO of the last feature in the list.
+ * REV - The revision of the feature associated with this header.
+ * ID - The feature ID if Type is private feature.
+
+- Offset 0x08
+
+ * GUID_L - Least significant 64 bits of a 128-bit Globally Unique Identifier
+ (present only if Type is FME or AFU).
+
+- Offset 0x10
+
+ * GUID_H - Most significant 64 bits of a 128-bit Globally Unique Identifier
+ (present only if Type is FME or AFU).
+
+
+Device Feature Header - Version 1
+=================================
+Version 1 (DFHv1) of the Device Feature Header adds the following functionality:
+
+* Provides a standardized mechanism for features to describe
+ parameters/capabilities to software.
+* Standardize the use of a GUID for all DFHv1 types.
+* Decouples the DFH location from the register space of the feature itself.
+
+The format of Version 1 of the Device Feature Header (DFH) is shown below::
+
+ +-----------------------------------------------------------------------+
+ |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID 0| 0x00
+ +-----------------------------------------------------------------------+
+ |63 GUID_L 0| 0x08
+ +-----------------------------------------------------------------------+
+ |63 GUID_H 0| 0x10
+ +-----------------------------------------------------------------------+
+ |63 Reg Address/Offset 1| Rel 0| 0x18
+ +-----------------------------------------------------------------------+
+ |63 Reg Size 32|Params 31|30 Group 16|15 Instance 0| 0x20
+ +-----------------------------------------------------------------------+
+ |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID 0| 0x28
+ +-----------------------------------------------------------------------+
+ |63 Parameter Data 0| 0x30
+ +-----------------------------------------------------------------------+
+
+ ...
+
+ +-----------------------------------------------------------------------+
+ |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID 0|
+ +-----------------------------------------------------------------------+
+ |63 Parameter Data 0|
+ +-----------------------------------------------------------------------+
+
+- Offset 0x00
+
+ * Type - The type of DFH (e.g. FME, AFU, or private feature).
+ * DFH VER - The version of the DFH.
+ * Rsvd - Currently unused.
+ * EOL - Set if the DFH is the end of the Device Feature List (DFL).
+ * Next - The offset in bytes of the next DFH in the DFL from the DFH start,
+ and the start of a DFH must be aligned to an 8 byte boundary.
+ If EOL is set, Next is the size of MMIO of the last feature in the list.
+ * REV - The revision of the feature associated with this header.
+ * ID - The feature ID if Type is private feature.
+
+- Offset 0x08
+
+ * GUID_L - Least significant 64 bits of a 128-bit Globally Unique Identifier.
+
+- Offset 0x10
+
+ * GUID_H - Most significant 64 bits of a 128-bit Globally Unique Identifier.
+
+- Offset 0x18
+
+ * Reg Address/Offset - If Rel bit is set, then the value is the high 63 bits
+ of a 16-bit aligned absolute address of the feature's registers. Otherwise
+ the value is the offset from the start of the DFH of the feature's registers.
+
+- Offset 0x20
+
+ * Reg Size - Size of feature's register set in bytes.
+ * Params - Set if DFH has a list of parameter blocks.
+ * Group - Id of group if feature is part of a group.
+ * Instance - Id of feature instance within a group.
+
+- Offset 0x28 if feature has parameters
+
+ * Next - Offset to the next parameter block in 8 byte words. If EOP set,
+ size in 8 byte words of last parameter.
+ * Param Version - Version of Param ID.
+ * Param ID - ID of parameter.
+
+- Offset 0x30
+
+ * Parameter Data - Parameter data whose size and format is defined by
+ version and ID of the parameter.
+
+
FIU - FME (FPGA Management Engine)
==================================
The FPGA Management Engine performs reconfiguration and other infrastructure
--
2.25.1
^ permalink raw reply related
* [PATCH v10 4/4] tty: serial: 8250: add DFL bus driver for Altera 16550.
From: matthew.gerlach @ 2023-01-10 0:30 UTC (permalink / raw)
To: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal,
trix, mdf, linux-fpga, linux-doc, linux-kernel, tianfei.zhang,
corbet, gregkh, linux-serial, jirislaby, geert+renesas,
andriy.shevchenko, niklas.soderlund+renesas, macro, johan, lukas,
ilpo.jarvinen, marpagan, bagasdotme
Cc: Matthew Gerlach
In-Reply-To: <20230110003029.806022-1-matthew.gerlach@linux.intel.com>
From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Add a Device Feature List (DFL) bus driver for the Altera
16550 implementation of UART.
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
v10: track change to dfh_find_param()
v9: add Rb Andy Shevchenko
move dfh_get_u64_param_vals to static version of dfh_get_u64_param_val
v8: use dfh_get_u64_param_vals()
v7: no change
v6: move driver specific parameter definitions to limit scope
v5: removed unneeded blank line
removed unneeded includes
included device.h and types.h
removed unneeded local variable
remove calls to dev_dbg
memset -> { }
remove space after period
explicitly include used headers
remove redundant Inc from Copyright
fix format specifier
v4: use dev_err_probe() everywhere that is appropriate
clean up noise
change error messages to use the word, unsupported
tried again to sort Makefile and KConfig better
reorder probe function for easier error handling
use new dfh_find_param API
v3: use passed in location of registers
use cleaned up functions for parsing parameters
v2: clean up error messages
alphabetize header files
fix 'missing prototype' error by making function static
tried to sort Makefile and Kconfig better
8250
---
drivers/tty/serial/8250/8250_dfl.c | 167 +++++++++++++++++++++++++++++
drivers/tty/serial/8250/Kconfig | 12 +++
drivers/tty/serial/8250/Makefile | 1 +
3 files changed, 180 insertions(+)
create mode 100644 drivers/tty/serial/8250/8250_dfl.c
diff --git a/drivers/tty/serial/8250/8250_dfl.c b/drivers/tty/serial/8250/8250_dfl.c
new file mode 100644
index 000000000000..1df443cab02e
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_dfl.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for FPGA UART
+ *
+ * Copyright (C) 2022 Intel Corporation.
+ *
+ * Authors:
+ * Ananda Ravuri <ananda.ravuri@intel.com>
+ * Matthew Gerlach <matthew.gerlach@linux.intel.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/device.h>
+#include <linux/dfl.h>
+#include <linux/errno.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/types.h>
+
+#include <linux/serial.h>
+#include <linux/serial_8250.h>
+
+#define DFHv1_PARAM_ID_CLK_FRQ 0x2
+#define DFHv1_PARAM_ID_FIFO_LEN 0x3
+
+#define DFHv1_PARAM_ID_REG_LAYOUT 0x4
+#define DFHv1_PARAM_REG_LAYOUT_WIDTH GENMASK_ULL(63, 32)
+#define DFHv1_PARAM_REG_LAYOUT_SHIFT GENMASK_ULL(31, 0)
+
+struct dfl_uart {
+ int line;
+};
+
+static int dfh_get_u64_param_val(struct dfl_device *dfl_dev, int param_id, u64 *pval)
+{
+ size_t psize;
+ u64 *p;
+
+ p = dfh_find_param(dfl_dev, param_id, &psize);
+ if (IS_ERR(p))
+ return PTR_ERR(p);
+
+ if (psize != sizeof(u64))
+ return -EINVAL;
+
+ *pval = *p;
+
+ return 0;
+}
+
+static int dfl_uart_get_params(struct dfl_device *dfl_dev, struct uart_8250_port *uart)
+{
+ struct device *dev = &dfl_dev->dev;
+ u64 fifo_len, clk_freq, reg_layout;
+ u32 reg_width;
+ int ret;
+
+ ret = dfh_get_u64_param_val(dfl_dev, DFHv1_PARAM_ID_CLK_FRQ, &clk_freq);
+ if (ret)
+ return dev_err_probe(dev, ret, "missing CLK_FRQ param\n");
+
+ uart->port.uartclk = clk_freq;
+
+ ret = dfh_get_u64_param_val(dfl_dev, DFHv1_PARAM_ID_FIFO_LEN, &fifo_len);
+ if (ret)
+ return dev_err_probe(dev, ret, "missing FIFO_LEN param\n");
+
+ switch (fifo_len) {
+ case 32:
+ uart->port.type = PORT_ALTR_16550_F32;
+ break;
+
+ case 64:
+ uart->port.type = PORT_ALTR_16550_F64;
+ break;
+
+ case 128:
+ uart->port.type = PORT_ALTR_16550_F128;
+ break;
+
+ default:
+ return dev_err_probe(dev, -EINVAL, "unsupported FIFO_LEN %llu\n", fifo_len);
+ }
+
+ ret = dfh_get_u64_param_val(dfl_dev, DFHv1_PARAM_ID_REG_LAYOUT, ®_layout);
+ if (ret)
+ return dev_err_probe(dev, ret, "missing REG_LAYOUT param\n");
+
+ uart->port.regshift = FIELD_GET(DFHv1_PARAM_REG_LAYOUT_SHIFT, reg_layout);
+ reg_width = FIELD_GET(DFHv1_PARAM_REG_LAYOUT_WIDTH, reg_layout);
+ switch (reg_width) {
+ case 4:
+ uart->port.iotype = UPIO_MEM32;
+ break;
+
+ case 2:
+ uart->port.iotype = UPIO_MEM16;
+ break;
+
+ default:
+ return dev_err_probe(dev, -EINVAL, "unsupported reg-width %u\n", reg_width);
+
+ }
+
+ return 0;
+}
+
+static int dfl_uart_probe(struct dfl_device *dfl_dev)
+{
+ struct device *dev = &dfl_dev->dev;
+ struct uart_8250_port uart = { };
+ struct dfl_uart *dfluart;
+ int ret;
+
+ uart.port.flags = UPF_IOREMAP;
+ uart.port.mapbase = dfl_dev->mmio_res.start;
+ uart.port.mapsize = resource_size(&dfl_dev->mmio_res);
+
+ ret = dfl_uart_get_params(dfl_dev, &uart);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed uart feature walk\n");
+
+ if (dfl_dev->num_irqs == 1)
+ uart.port.irq = dfl_dev->irqs[0];
+
+ dfluart = devm_kzalloc(dev, sizeof(*dfluart), GFP_KERNEL);
+ if (!dfluart)
+ return -ENOMEM;
+
+ dfluart->line = serial8250_register_8250_port(&uart);
+ if (dfluart->line < 0)
+ return dev_err_probe(dev, dfluart->line, "unable to register 8250 port.\n");
+
+ dev_set_drvdata(dev, dfluart);
+
+ return 0;
+}
+
+static void dfl_uart_remove(struct dfl_device *dfl_dev)
+{
+ struct dfl_uart *dfluart = dev_get_drvdata(&dfl_dev->dev);
+
+ serial8250_unregister_port(dfluart->line);
+}
+
+#define FME_FEATURE_ID_UART 0x24
+
+static const struct dfl_device_id dfl_uart_ids[] = {
+ { FME_ID, FME_FEATURE_ID_UART },
+ { }
+};
+MODULE_DEVICE_TABLE(dfl, dfl_uart_ids);
+
+static struct dfl_driver dfl_uart_driver = {
+ .drv = {
+ .name = "dfl-uart",
+ },
+ .id_table = dfl_uart_ids,
+ .probe = dfl_uart_probe,
+ .remove = dfl_uart_remove,
+};
+module_dfl_driver(dfl_uart_driver);
+
+MODULE_DESCRIPTION("DFL Intel UART driver");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL");
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index b0f62345bc84..08af2acd4645 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -370,6 +370,18 @@ config SERIAL_8250_FSL
erratum for Freescale 16550 UARTs in the 8250 driver. It also
enables support for ACPI enumeration.
+config SERIAL_8250_DFL
+ tristate "DFL bus driver for Altera 16550 UART"
+ depends on SERIAL_8250 && FPGA_DFL
+ help
+ This option enables support for a Device Feature List (DFL) bus
+ driver for the Altera 16650 UART. One or more Altera 16650 UARTs
+ can be instantiated in a FPGA and then be discovered during
+ enumeration of the DFL bus.
+
+ To compile this driver as a module, chose M here: the
+ module will be called 8250_dfl.
+
config SERIAL_8250_DW
tristate "Support for Synopsys DesignWare 8250 quirks"
depends on SERIAL_8250
diff --git a/drivers/tty/serial/8250/Makefile b/drivers/tty/serial/8250/Makefile
index 1615bfdde2a0..4e1a32812683 100644
--- a/drivers/tty/serial/8250/Makefile
+++ b/drivers/tty/serial/8250/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_SERIAL_8250_EXAR_ST16C554) += 8250_exar_st16c554.o
obj-$(CONFIG_SERIAL_8250_HUB6) += 8250_hub6.o
obj-$(CONFIG_SERIAL_8250_FSL) += 8250_fsl.o
obj-$(CONFIG_SERIAL_8250_MEN_MCB) += 8250_men_mcb.o
+obj-$(CONFIG_SERIAL_8250_DFL) += 8250_dfl.o
obj-$(CONFIG_SERIAL_8250_DW) += 8250_dw.o
obj-$(CONFIG_SERIAL_8250_EM) += 8250_em.o
obj-$(CONFIG_SERIAL_8250_IOC3) += 8250_ioc3.o
--
2.25.1
^ permalink raw reply related
* [PATCH v10 3/4] fpga: dfl: add basic support for DFHv1
From: matthew.gerlach @ 2023-01-10 0:30 UTC (permalink / raw)
To: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal,
trix, mdf, linux-fpga, linux-doc, linux-kernel, tianfei.zhang,
corbet, gregkh, linux-serial, jirislaby, geert+renesas,
andriy.shevchenko, niklas.soderlund+renesas, macro, johan, lukas,
ilpo.jarvinen, marpagan, bagasdotme
Cc: Matthew Gerlach
In-Reply-To: <20230110003029.806022-1-matthew.gerlach@linux.intel.com>
From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Version 1 of the Device Feature Header (DFH) definition adds
functionality to the Device Feature List (DFL) bus.
A DFHv1 header may have one or more parameter blocks that
further describes the HW to SW. Add support to the DFL bus
to parse the MSI-X parameter.
The location of a feature's register set is explicitly
described in DFHv1 and can be relative to the base of the DFHv1
or an absolute address. Parse the location and pass the information
to DFL driver.
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
v10: change dfh_find_param to return size of parameter data in bytes
v9: fix spacing errors in commit message and code
s/dfh_get_psize/dfh_get_param_size/
put new structure members at the end of the stucture
update dfh_find_param API
remove dfh_get_u64_param_vals
v8: use struct_size() from overflow.h
add dfh_get_u64_param_vals()
v7: no change
v6: move MSI_X parameter definitions to drivers/fpga/dfl.h
v5: update field names
fix find_param/dfh_get_psize
clean up mmio_res assignments
use u64* instead of void*
use FIELD_GET instead of masking
v4: s/MSIX/MSI_X
move kernel doc to implementation
use structure assignment
fix decode of absolute address
clean up comment in parse_feature_irqs
remove use of csr_res
v3: remove unneeded blank line
use clearer variable name
pass finfo into parse_feature_irqs()
refactor code for better indentation
use switch statement for irq parsing
squash in code parsing register location
v2: fix kernel doc
clarify use of DFH_VERSION field
---
drivers/fpga/dfl.c | 245 +++++++++++++++++++++++++++++++++++---------
drivers/fpga/dfl.h | 11 ++
include/linux/dfl.h | 8 ++
3 files changed, 213 insertions(+), 51 deletions(-)
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index b9aae85ba930..0a4227bc9462 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -13,6 +13,7 @@
#include <linux/dfl.h>
#include <linux/fpga-dfl.h>
#include <linux/module.h>
+#include <linux/overflow.h>
#include <linux/uaccess.h>
#include "dfl.h"
@@ -342,6 +343,8 @@ static void release_dfl_dev(struct device *dev)
if (ddev->mmio_res.parent)
release_resource(&ddev->mmio_res);
+ kfree(ddev->params);
+
ida_free(&dfl_device_ida, ddev->id);
kfree(ddev->irqs);
kfree(ddev);
@@ -380,7 +383,16 @@ dfl_dev_add(struct dfl_feature_platform_data *pdata,
ddev->type = feature_dev_id_type(pdev);
ddev->feature_id = feature->id;
ddev->revision = feature->revision;
+ ddev->dfh_version = feature->dfh_version;
ddev->cdev = pdata->dfl_cdev;
+ if (feature->param_size) {
+ ddev->params = kmemdup(feature->params, feature->param_size, GFP_KERNEL);
+ if (!ddev->params) {
+ ret = -ENOMEM;
+ goto put_dev;
+ }
+ ddev->param_size = feature->param_size;
+ }
/* add mmio resource */
parent_res = &pdev->resource[feature->resource_index];
@@ -708,20 +720,27 @@ struct build_feature_devs_info {
* struct dfl_feature_info - sub feature info collected during feature dev build
*
* @fid: id of this sub feature.
+ * @revision: revision of this sub feature
+ * @dfh_version: version of Device Feature Header (DFH)
* @mmio_res: mmio resource of this sub feature.
* @ioaddr: mapped base address of mmio resource.
* @node: node in sub_features linked list.
* @irq_base: start of irq index in this sub feature.
* @nr_irqs: number of irqs of this sub feature.
+ * @param_size: size DFH parameters.
+ * @params: DFH parameter data.
*/
struct dfl_feature_info {
u16 fid;
u8 revision;
+ u8 dfh_version;
struct resource mmio_res;
void __iomem *ioaddr;
struct list_head node;
unsigned int irq_base;
unsigned int nr_irqs;
+ unsigned int param_size;
+ u64 params[];
};
static void dfl_fpga_cdev_add_port_dev(struct dfl_fpga_cdev *cdev,
@@ -797,7 +816,17 @@ static int build_info_commit_dev(struct build_feature_devs_info *binfo)
feature->dev = fdev;
feature->id = finfo->fid;
feature->revision = finfo->revision;
+ feature->dfh_version = finfo->dfh_version;
+ if (finfo->param_size) {
+ feature->params = devm_kmemdup(binfo->dev,
+ finfo->params, finfo->param_size,
+ GFP_KERNEL);
+ if (!feature->params)
+ return -ENOMEM;
+
+ feature->param_size = finfo->param_size;
+ }
/*
* the FIU header feature has some fundamental functions (sriov
* set, port enable/disable) needed for the dfl bus device and
@@ -934,56 +963,115 @@ static u16 feature_id(u64 value)
return 0;
}
+static u64 *find_param(u64 *params, resource_size_t max, int param_id)
+{
+ u64 *end = params + max / sizeof(u64);
+ u64 v, next;
+
+ while (params < end) {
+ v = *params;
+ if (param_id == FIELD_GET(DFHv1_PARAM_HDR_ID, v))
+ return params;
+
+ if (FIELD_GET(DFHv1_PARAM_HDR_NEXT_EOP, v))
+ break;
+
+ next = FIELD_GET(DFHv1_PARAM_HDR_NEXT_OFFSET, v);
+ params += next;
+ }
+
+ return NULL;
+}
+
+/**
+ * dfh_find_param() - find parameter block for the given parameter id
+ * @dfl_dev: dfl device
+ * @param_id: id of dfl parameter
+ * @psize: destination to store size of parameter data in bytes
+ *
+ * Return: pointer to start of parameter data, PTR_ERR otherwise.
+ */
+void *dfh_find_param(struct dfl_device *dfl_dev, int param_id, size_t *psize)
+{
+ u64 *phdr = find_param(dfl_dev->params, dfl_dev->param_size, param_id);
+
+ if (!phdr)
+ return ERR_PTR(-ENOENT);
+
+ if (psize)
+ *psize = (FIELD_GET(DFHv1_PARAM_HDR_NEXT_OFFSET, *phdr) - 1) * sizeof(u64);
+
+ return phdr + 1;
+}
+EXPORT_SYMBOL_GPL(dfh_find_param);
+
static int parse_feature_irqs(struct build_feature_devs_info *binfo,
- resource_size_t ofst, u16 fid,
- unsigned int *irq_base, unsigned int *nr_irqs)
+ resource_size_t ofst, struct dfl_feature_info *finfo)
{
void __iomem *base = binfo->ioaddr + ofst;
unsigned int i, ibase, inr = 0;
+ void *params = finfo->params;
enum dfl_id_type type;
+ u16 fid = finfo->fid;
int virq;
+ u64 *p;
u64 v;
- type = feature_dev_id_type(binfo->feature_dev);
+ switch (finfo->dfh_version) {
+ case 0:
+ /*
+ * DFHv0 only provides MMIO resource information for each feature
+ * in the DFL header. There is no generic interrupt information.
+ * Instead, features with interrupt functionality provide
+ * the information in feature specific registers.
+ */
+ type = feature_dev_id_type(binfo->feature_dev);
+ if (type == PORT_ID) {
+ switch (fid) {
+ case PORT_FEATURE_ID_UINT:
+ v = readq(base + PORT_UINT_CAP);
+ ibase = FIELD_GET(PORT_UINT_CAP_FST_VECT, v);
+ inr = FIELD_GET(PORT_UINT_CAP_INT_NUM, v);
+ break;
+ case PORT_FEATURE_ID_ERROR:
+ v = readq(base + PORT_ERROR_CAP);
+ ibase = FIELD_GET(PORT_ERROR_CAP_INT_VECT, v);
+ inr = FIELD_GET(PORT_ERROR_CAP_SUPP_INT, v);
+ break;
+ }
+ } else if (type == FME_ID) {
+ switch (fid) {
+ case FME_FEATURE_ID_GLOBAL_ERR:
+ v = readq(base + FME_ERROR_CAP);
+ ibase = FIELD_GET(FME_ERROR_CAP_INT_VECT, v);
+ inr = FIELD_GET(FME_ERROR_CAP_SUPP_INT, v);
+ break;
+ }
+ }
+ break;
- /*
- * Ideally DFL framework should only read info from DFL header, but
- * current version DFL only provides mmio resources information for
- * each feature in DFL Header, no field for interrupt resources.
- * Interrupt resource information is provided by specific mmio
- * registers of each private feature which supports interrupt. So in
- * order to parse and assign irq resources, DFL framework has to look
- * into specific capability registers of these private features.
- *
- * Once future DFL version supports generic interrupt resource
- * information in common DFL headers, the generic interrupt parsing
- * code will be added. But in order to be compatible to old version
- * DFL, the driver may still fall back to these quirks.
- */
- if (type == PORT_ID) {
- switch (fid) {
- case PORT_FEATURE_ID_UINT:
- v = readq(base + PORT_UINT_CAP);
- ibase = FIELD_GET(PORT_UINT_CAP_FST_VECT, v);
- inr = FIELD_GET(PORT_UINT_CAP_INT_NUM, v);
- break;
- case PORT_FEATURE_ID_ERROR:
- v = readq(base + PORT_ERROR_CAP);
- ibase = FIELD_GET(PORT_ERROR_CAP_INT_VECT, v);
- inr = FIELD_GET(PORT_ERROR_CAP_SUPP_INT, v);
+ case 1:
+ /*
+ * DFHv1 provides interrupt resource information in DFHv1
+ * parameter blocks.
+ */
+ p = find_param(params, finfo->param_size, DFHv1_PARAM_ID_MSI_X);
+ if (!p)
break;
- }
- } else if (type == FME_ID) {
- if (fid == FME_FEATURE_ID_GLOBAL_ERR) {
- v = readq(base + FME_ERROR_CAP);
- ibase = FIELD_GET(FME_ERROR_CAP_INT_VECT, v);
- inr = FIELD_GET(FME_ERROR_CAP_SUPP_INT, v);
- }
+
+ p++;
+ ibase = FIELD_GET(DFHv1_PARAM_MSI_X_STARTV, *p);
+ inr = FIELD_GET(DFHv1_PARAM_MSI_X_NUMV, *p);
+ break;
+
+ default:
+ dev_warn(binfo->dev, "unexpected DFH version %d\n", finfo->dfh_version);
+ break;
}
if (!inr) {
- *irq_base = 0;
- *nr_irqs = 0;
+ finfo->irq_base = 0;
+ finfo->nr_irqs = 0;
return 0;
}
@@ -1006,12 +1094,37 @@ static int parse_feature_irqs(struct build_feature_devs_info *binfo,
}
}
- *irq_base = ibase;
- *nr_irqs = inr;
+ finfo->irq_base = ibase;
+ finfo->nr_irqs = inr;
return 0;
}
+static int dfh_get_param_size(void __iomem *dfh_base, resource_size_t max)
+{
+ int size = 0;
+ u64 v, next;
+
+ if (!FIELD_GET(DFHv1_CSR_SIZE_GRP_HAS_PARAMS,
+ readq(dfh_base + DFHv1_CSR_SIZE_GRP)))
+ return 0;
+
+ while (size + DFHv1_PARAM_HDR < max) {
+ v = readq(dfh_base + DFHv1_PARAM_HDR + size);
+
+ next = FIELD_GET(DFHv1_PARAM_HDR_NEXT_OFFSET, v);
+ if (!next)
+ return -EINVAL;
+
+ size += next * sizeof(u64);
+
+ if (FIELD_GET(DFHv1_PARAM_HDR_NEXT_EOP, v))
+ return size;
+ }
+
+ return -ENOENT;
+}
+
/*
* when create sub feature instances, for private features, it doesn't need
* to provide resource size and feature id as they could be read from DFH
@@ -1023,39 +1136,69 @@ static int
create_feature_instance(struct build_feature_devs_info *binfo,
resource_size_t ofst, resource_size_t size, u16 fid)
{
- unsigned int irq_base, nr_irqs;
struct dfl_feature_info *finfo;
+ resource_size_t start, end;
+ int dfh_psize = 0;
u8 revision = 0;
+ u64 v, addr_off;
+ u8 dfh_ver = 0;
int ret;
- u64 v;
if (fid != FEATURE_ID_AFU) {
v = readq(binfo->ioaddr + ofst);
revision = FIELD_GET(DFH_REVISION, v);
-
+ dfh_ver = FIELD_GET(DFH_VERSION, v);
/* read feature size and id if inputs are invalid */
size = size ? size : feature_size(v);
fid = fid ? fid : feature_id(v);
+ if (dfh_ver == 1) {
+ dfh_psize = dfh_get_param_size(binfo->ioaddr + ofst, size);
+ if (dfh_psize < 0) {
+ dev_err(binfo->dev,
+ "failed to read size of DFHv1 parameters %d\n",
+ dfh_psize);
+ return dfh_psize;
+ }
+ dev_dbg(binfo->dev, "dfhv1_psize %d\n", dfh_psize);
+ }
}
if (binfo->len - ofst < size)
return -EINVAL;
- ret = parse_feature_irqs(binfo, ofst, fid, &irq_base, &nr_irqs);
- if (ret)
- return ret;
-
- finfo = kzalloc(sizeof(*finfo), GFP_KERNEL);
+ finfo = kzalloc(struct_size(finfo, params, dfh_psize / sizeof(u64)), GFP_KERNEL);
if (!finfo)
return -ENOMEM;
+ memcpy_fromio(finfo->params, binfo->ioaddr + ofst + DFHv1_PARAM_HDR, dfh_psize);
+ finfo->param_size = dfh_psize;
+
finfo->fid = fid;
finfo->revision = revision;
- finfo->mmio_res.start = binfo->start + ofst;
- finfo->mmio_res.end = finfo->mmio_res.start + size - 1;
+ finfo->dfh_version = dfh_ver;
+ if (dfh_ver == 1) {
+ v = readq(binfo->ioaddr + ofst + DFHv1_CSR_ADDR);
+ addr_off = FIELD_GET(DFHv1_CSR_ADDR_MASK, v);
+ if (FIELD_GET(DFHv1_CSR_ADDR_REL, v))
+ start = addr_off << 1;
+ else
+ start = binfo->start + ofst + addr_off;
+
+ v = readq(binfo->ioaddr + ofst + DFHv1_CSR_SIZE_GRP);
+ end = start + FIELD_GET(DFHv1_CSR_SIZE_GRP_SIZE, v) - 1;
+ } else {
+ start = binfo->start + ofst;
+ end = start + size - 1;
+ }
finfo->mmio_res.flags = IORESOURCE_MEM;
- finfo->irq_base = irq_base;
- finfo->nr_irqs = nr_irqs;
+ finfo->mmio_res.start = start;
+ finfo->mmio_res.end = end;
+
+ ret = parse_feature_irqs(binfo, ofst, finfo);
+ if (ret) {
+ kfree(finfo);
+ return ret;
+ }
list_add_tail(&finfo->node, &binfo->sub_features);
binfo->feature_num++;
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index fc59f33367ee..20eaddce6988 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -111,6 +111,10 @@
#define DFHv1_PARAM_HDR_NEXT_EOP BIT_ULL(32)
#define DFHv1_PARAM_DATA 0x08 /* Offset of Param data from Param header */
+#define DFHv1_PARAM_ID_MSI_X 0x1
+#define DFHv1_PARAM_MSI_X_NUMV GENMASK_ULL(63, 32)
+#define DFHv1_PARAM_MSI_X_STARTV GENMASK_ULL(31, 0)
+
/* Next AFU Register Bitfield */
#define NEXT_AFU_NEXT_DFH_OFST GENMASK_ULL(23, 0) /* Offset to next AFU */
@@ -263,6 +267,7 @@ struct dfl_feature_irq_ctx {
*
* @dev: ptr to pdev of the feature device which has the sub feature.
* @id: sub feature id.
+ * @revision: revisition of the instance of a feature.
* @resource_index: each sub feature has one mmio resource for its registers.
* this index is used to find its mmio resource from the
* feature dev (platform device)'s resources.
@@ -272,6 +277,9 @@ struct dfl_feature_irq_ctx {
* @ops: ops of this sub feature.
* @ddev: ptr to the dfl device of this sub feature.
* @priv: priv data of this feature.
+ * @dfh_version: version of the DFH
+ * @param_size: size of dfh parameters
+ * @params: point to memory copy of dfh parameters
*/
struct dfl_feature {
struct platform_device *dev;
@@ -284,6 +292,9 @@ struct dfl_feature {
const struct dfl_feature_ops *ops;
struct dfl_device *ddev;
void *priv;
+ u8 dfh_version;
+ unsigned int param_size;
+ void *params;
};
#define FEATURE_DEV_ID_UNUSED (-1)
diff --git a/include/linux/dfl.h b/include/linux/dfl.h
index 431636a0dc78..0a7a00a0ee7f 100644
--- a/include/linux/dfl.h
+++ b/include/linux/dfl.h
@@ -27,11 +27,15 @@ enum dfl_id_type {
* @id: id of the dfl device.
* @type: type of DFL FIU of the device. See enum dfl_id_type.
* @feature_id: feature identifier local to its DFL FIU type.
+ * @revision: revision of this dfl device feature.
* @mmio_res: mmio resource of this dfl device.
* @irqs: list of Linux IRQ numbers of this dfl device.
* @num_irqs: number of IRQs supported by this dfl device.
* @cdev: pointer to DFL FPGA container device this dfl device belongs to.
* @id_entry: matched id entry in dfl driver's id table.
+ * @dfh_version: version of DFH for the device
+ * @param_size: size of the block parameters in bytes
+ * @params: pointer to block of parameters copied memory
*/
struct dfl_device {
struct device dev;
@@ -44,6 +48,9 @@ struct dfl_device {
unsigned int num_irqs;
struct dfl_fpga_cdev *cdev;
const struct dfl_device_id *id_entry;
+ u8 dfh_version;
+ unsigned int param_size;
+ void *params;
};
/**
@@ -84,4 +91,5 @@ void dfl_driver_unregister(struct dfl_driver *dfl_drv);
module_driver(__dfl_driver, dfl_driver_register, \
dfl_driver_unregister)
+void *dfh_find_param(struct dfl_device *dfl_dev, int param_id, size_t *pcount);
#endif /* __LINUX_DFL_H */
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 1/2] tty: serial: dz: convert atomic_* to refcount_* APIs for map_guard
From: Deepak R Varma @ 2023-01-10 6:19 UTC (permalink / raw)
To: Jiri Slaby
Cc: Maciej W. Rozycki, Greg Kroah-Hartman, linux-serial, linux-kernel,
Saurabh Singh Sengar, Praveen Kumar, elena.reshetova, ishkamiel,
keescook, dwindsor, Deepak R Varma
In-Reply-To: <e42d5d19-7ed5-468b-98cc-13d0187dc555@kernel.org>
On Tue, Jan 03, 2023 at 09:59:52AM +0100, Jiri Slaby wrote:
> On 26. 12. 22, 7:21, Deepak R Varma wrote:
> > The refcount_* APIs are designed to address known issues with the
> > atomic_t APIs for reference counting. They provide following distinct
> > advantages
> > - protect the reference counters from overflow/underflow
> > - avoid use-after-free errors
> > - provide improved memory ordering guarantee schemes
> > - neater and safer.
>
> Really? (see below)
>
> > --- a/drivers/tty/serial/dz.c
> > +++ b/drivers/tty/serial/dz.c
> ...
> > @@ -687,23 +686,19 @@ static int dz_map_port(struct uart_port *uport)
> > static int dz_request_port(struct uart_port *uport)
> > {
> > struct dz_mux *mux = to_dport(uport)->mux;
> > - int map_guard;
> > int ret;
> >
> > - map_guard = atomic_add_return(1, &mux->map_guard);
> > - if (map_guard == 1) {
> > - if (!request_mem_region(uport->mapbase, dec_kn_slot_size,
> > - "dz")) {
> > - atomic_add(-1, &mux->map_guard);
> > - printk(KERN_ERR
> > - "dz: Unable to reserve MMIO resource\n");
> > + refcount_inc(&mux->map_guard);
> > + if (refcount_read(&mux->map_guard) == 1) {
>
> This is now racy, right?
Hello Jiri,
I found this [1] commit which introduced similar transformation in a
neighbouring driver. Can you please comment how is this different from the
current patch proposal?
[1] commit ID: 22a33651a56f ("convert sbd_duart.map_guard from atomic_t to refcount_t")
On a side note, I have not been able to find an exact 1:1 map to the
atomic_add_result API. I am wondering should we have one?
Thank you,
./drv
Thank you,
./drv
>
> thanks,
> --
> js
> suse labs
>
^ permalink raw reply
* RE: [PATCH v4 1/2] tty: serial: dz: convert atomic_* to refcount_* APIs for map_guard
From: Reshetova, Elena @ 2023-01-10 7:27 UTC (permalink / raw)
To: Deepak R Varma, Jiri Slaby
Cc: Maciej W. Rozycki, Greg Kroah-Hartman,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
Saurabh Singh Sengar, Praveen Kumar, ishkamiel@gmail.com,
keescook@chromium.org, dwindsor@gmail.com
In-Reply-To: <Y70DbEvxDDGXDv4i@ubun2204.myguest.virtualbox.org>
> On Tue, Jan 03, 2023 at 09:59:52AM +0100, Jiri Slaby wrote:
> > On 26. 12. 22, 7:21, Deepak R Varma wrote:
> > > The refcount_* APIs are designed to address known issues with the
> > > atomic_t APIs for reference counting. They provide following distinct
> > > advantages
> > > - protect the reference counters from overflow/underflow
> > > - avoid use-after-free errors
> > > - provide improved memory ordering guarantee schemes
> > > - neater and safer.
> >
> > Really? (see below)
> >
> > > --- a/drivers/tty/serial/dz.c
> > > +++ b/drivers/tty/serial/dz.c
> > ...
> > > @@ -687,23 +686,19 @@ static int dz_map_port(struct uart_port *uport)
> > > static int dz_request_port(struct uart_port *uport)
> > > {
> > > struct dz_mux *mux = to_dport(uport)->mux;
> > > - int map_guard;
> > > int ret;
> > >
> > > - map_guard = atomic_add_return(1, &mux->map_guard);
> > > - if (map_guard == 1) {
> > > - if (!request_mem_region(uport->mapbase, dec_kn_slot_size,
> > > - "dz")) {
> > > - atomic_add(-1, &mux->map_guard);
> > > - printk(KERN_ERR
> > > - "dz: Unable to reserve MMIO resource\n");
> > > + refcount_inc(&mux->map_guard);
> > > + if (refcount_read(&mux->map_guard) == 1) {
> >
> > This is now racy, right?
>
> Hello Jiri,
> I found this [1] commit which introduced similar transformation in a
> neighbouring driver. Can you please comment how is this different from the
> current patch proposal?
>
> [1] commit ID: 22a33651a56f ("convert sbd_duart.map_guard from atomic_t to
> refcount_t")
>
> On a side note, I have not been able to find an exact 1:1 map to the
> atomic_add_result API. I am wondering should we have one?
In past we have decided not to provide this API for refcount_t
because for truly correctly behaving reference counters it should not be needed
(vs atomics that cover a broader range of use cases).
Can you use !refcount_inc_not_zero in the above case?
Best Regards,
Elena.
^ permalink raw reply
* Re: [PATCH v4 1/2] tty: serial: dz: convert atomic_* to refcount_* APIs for map_guard
From: Deepak R Varma @ 2023-01-10 7:47 UTC (permalink / raw)
To: Reshetova, Elena
Cc: Jiri Slaby, Maciej W. Rozycki, Greg Kroah-Hartman,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
Saurabh Singh Sengar, Praveen Kumar, ishkamiel@gmail.com,
keescook@chromium.org, dwindsor@gmail.com
In-Reply-To: <DM8PR11MB575088A17680C124D6B9EB73E7FF9@DM8PR11MB5750.namprd11.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
On Tue, Jan 10, 2023 at 07:27:44AM +0000, Reshetova, Elena wrote:
>
> > On Tue, Jan 03, 2023 at 09:59:52AM +0100, Jiri Slaby wrote:
> > > On 26. 12. 22, 7:21, Deepak R Varma wrote:
> > > > The refcount_* APIs are designed to address known issues with the
> > > > atomic_t APIs for reference counting. They provide following distinct
> > > > advantages
> > > > - protect the reference counters from overflow/underflow
> > > > - avoid use-after-free errors
> > > > - provide improved memory ordering guarantee schemes
> > > > - neater and safer.
> > >
> > > Really? (see below)
> > >
> > > > --- a/drivers/tty/serial/dz.c
> > > > +++ b/drivers/tty/serial/dz.c
> > > ...
> > > > @@ -687,23 +686,19 @@ static int dz_map_port(struct uart_port *uport)
> > > > static int dz_request_port(struct uart_port *uport)
> > > > {
> > > > struct dz_mux *mux = to_dport(uport)->mux;
> > > > - int map_guard;
> > > > int ret;
> > > >
> > > > - map_guard = atomic_add_return(1, &mux->map_guard);
> > > > - if (map_guard == 1) {
> > > > - if (!request_mem_region(uport->mapbase, dec_kn_slot_size,
> > > > - "dz")) {
> > > > - atomic_add(-1, &mux->map_guard);
> > > > - printk(KERN_ERR
> > > > - "dz: Unable to reserve MMIO resource\n");
> > > > + refcount_inc(&mux->map_guard);
> > > > + if (refcount_read(&mux->map_guard) == 1) {
> > >
> > > This is now racy, right?
> >
> > Hello Jiri,
> > I found this [1] commit which introduced similar transformation in a
> > neighbouring driver. Can you please comment how is this different from the
> > current patch proposal?
> >
> > [1] commit ID: 22a33651a56f ("convert sbd_duart.map_guard from atomic_t to
> > refcount_t")
> >
> > On a side note, I have not been able to find an exact 1:1 map to the
> > atomic_add_result API. I am wondering should we have one?
>
Hello Elena,
> In past we have decided not to provide this API for refcount_t
> because for truly correctly behaving reference counters it should not be needed
> (vs atomics that cover a broader range of use cases).
So, there is no FAA refcount wrapper? I think this is a pretty common need.
Please correct me if I am wrong.
> Can you use !refcount_inc_not_zero in the above case?
I actually did try that but was not sure if truly addresses the objection.
Please attached and let me know if you have a feedback on the alternate
approach.
Thank you,
./drv
>
> Best Regards,
> Elena.
[-- Attachment #2: code_diff --]
[-- Type: text/plain, Size: 1419 bytes --]
############## ORIGINAL CODE ##################################
- map_guard = atomic_add_return(1, &mux->map_guard);
- if (map_guard == 1) {
- if (!request_mem_region(uport->mapbase, dec_kn_slot_size,
- "dz")) {
- atomic_add(-1, &mux->map_guard);
- printk(KERN_ERR
- "dz: Unable to reserve MMIO resource\n");
return -EBUSY;
}
}
############## INITIAL APPROACH ##################################
+ refcount_inc(&mux->map_guard);
+ if (refcount_read(&mux->map_guard) == 1) {
+ if (!request_mem_region(uport->mapbase, dec_kn_slot_size, "dz")) {
+ refcount_dec(&mux->map_guard);
+ printk(KERN_ERR "dz: Unable to reserve MMIO resource\n");
return -EBUSY;
}
}
############## ALTERNATE APPROACH ##################################
+ if (!refcount_inc_not_zero(&mux->map_guard)) {
+ refcount_inc(&mux->map_guard);
+ if (!request_mem_region(uport->mapbase, dec_kn_slot_size, "dz")) {
+ refcount_dec(&mux->map_guard);
+ printk(KERN_ERR "dz: Unable to reserve MMIO resource\n");
return -EBUSY;
}
}
^ permalink raw reply
* Re: [PATCH v4 1/2] tty: serial: dz: convert atomic_* to refcount_* APIs for map_guard
From: Greg Kroah-Hartman @ 2023-01-10 7:57 UTC (permalink / raw)
To: Deepak R Varma
Cc: Reshetova, Elena, Jiri Slaby, Maciej W. Rozycki,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
Saurabh Singh Sengar, Praveen Kumar, ishkamiel@gmail.com,
keescook@chromium.org, dwindsor@gmail.com
In-Reply-To: <Y70YKqt+Ej4kU9+h@ubun2204.myguest.virtualbox.org>
On Tue, Jan 10, 2023 at 01:17:54PM +0530, Deepak R Varma wrote:
> On Tue, Jan 10, 2023 at 07:27:44AM +0000, Reshetova, Elena wrote:
> >
> > > On Tue, Jan 03, 2023 at 09:59:52AM +0100, Jiri Slaby wrote:
> > > > On 26. 12. 22, 7:21, Deepak R Varma wrote:
> > > > > The refcount_* APIs are designed to address known issues with the
> > > > > atomic_t APIs for reference counting. They provide following distinct
> > > > > advantages
> > > > > - protect the reference counters from overflow/underflow
> > > > > - avoid use-after-free errors
> > > > > - provide improved memory ordering guarantee schemes
> > > > > - neater and safer.
> > > >
> > > > Really? (see below)
> > > >
> > > > > --- a/drivers/tty/serial/dz.c
> > > > > +++ b/drivers/tty/serial/dz.c
> > > > ...
> > > > > @@ -687,23 +686,19 @@ static int dz_map_port(struct uart_port *uport)
> > > > > static int dz_request_port(struct uart_port *uport)
> > > > > {
> > > > > struct dz_mux *mux = to_dport(uport)->mux;
> > > > > - int map_guard;
> > > > > int ret;
> > > > >
> > > > > - map_guard = atomic_add_return(1, &mux->map_guard);
> > > > > - if (map_guard == 1) {
> > > > > - if (!request_mem_region(uport->mapbase, dec_kn_slot_size,
> > > > > - "dz")) {
> > > > > - atomic_add(-1, &mux->map_guard);
> > > > > - printk(KERN_ERR
> > > > > - "dz: Unable to reserve MMIO resource\n");
> > > > > + refcount_inc(&mux->map_guard);
> > > > > + if (refcount_read(&mux->map_guard) == 1) {
> > > >
> > > > This is now racy, right?
> > >
> > > Hello Jiri,
> > > I found this [1] commit which introduced similar transformation in a
> > > neighbouring driver. Can you please comment how is this different from the
> > > current patch proposal?
> > >
> > > [1] commit ID: 22a33651a56f ("convert sbd_duart.map_guard from atomic_t to
> > > refcount_t")
> > >
> > > On a side note, I have not been able to find an exact 1:1 map to the
> > > atomic_add_result API. I am wondering should we have one?
> >
>
> Hello Elena,
>
> > In past we have decided not to provide this API for refcount_t
> > because for truly correctly behaving reference counters it should not be needed
> > (vs atomics that cover a broader range of use cases).
>
> So, there is no FAA refcount wrapper? I think this is a pretty common need.
> Please correct me if I am wrong.
>
> > Can you use !refcount_inc_not_zero in the above case?
>
> I actually did try that but was not sure if truly addresses the objection.
> Please attached and let me know if you have a feedback on the alternate
> approach.
>
> Thank you,
> ./drv
>
>
> >
> > Best Regards,
> > Elena.
> ############## ORIGINAL CODE ##################################
> - map_guard = atomic_add_return(1, &mux->map_guard);
> - if (map_guard == 1) {
> - if (!request_mem_region(uport->mapbase, dec_kn_slot_size,
> - "dz")) {
> - atomic_add(-1, &mux->map_guard);
> - printk(KERN_ERR
> - "dz: Unable to reserve MMIO resource\n");
> return -EBUSY;
> }
> }
>
> ############## INITIAL APPROACH ##################################
> + refcount_inc(&mux->map_guard);
> + if (refcount_read(&mux->map_guard) == 1) {
> + if (!request_mem_region(uport->mapbase, dec_kn_slot_size, "dz")) {
> + refcount_dec(&mux->map_guard);
> + printk(KERN_ERR "dz: Unable to reserve MMIO resource\n");
> return -EBUSY;
> }
> }
>
> ############## ALTERNATE APPROACH ##################################
>
> + if (!refcount_inc_not_zero(&mux->map_guard)) {
> + refcount_inc(&mux->map_guard);
> + if (!request_mem_region(uport->mapbase, dec_kn_slot_size, "dz")) {
> + refcount_dec(&mux->map_guard);
> + printk(KERN_ERR "dz: Unable to reserve MMIO resource\n");
> return -EBUSY;
> }
> }
>
This feels odd to me, why not just use a normal lock instead?
thanks,
greg k-h
^ permalink raw reply
* Słowa kluczowe do wypozycjonowania
From: Adam Charachuta @ 2023-01-10 8:40 UTC (permalink / raw)
To: linux-serial
Dzień dobry,
zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów.
Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci.
Możemy porozmawiać w najbliższym czasie?
Pozdrawiam
Adam Charachuta
^ permalink raw reply
* Re: [PATCH v10 3/4] fpga: dfl: add basic support for DFHv1
From: Andy Shevchenko @ 2023-01-10 10:21 UTC (permalink / raw)
To: matthew.gerlach
Cc: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal,
trix, mdf, linux-fpga, linux-doc, linux-kernel, tianfei.zhang,
corbet, gregkh, linux-serial, jirislaby, geert+renesas,
niklas.soderlund+renesas, macro, johan, lukas, ilpo.jarvinen,
marpagan, bagasdotme
In-Reply-To: <20230110003029.806022-4-matthew.gerlach@linux.intel.com>
On Mon, Jan 09, 2023 at 04:30:28PM -0800, matthew.gerlach@linux.intel.com wrote:
> From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
>
> Version 1 of the Device Feature Header (DFH) definition adds
> functionality to the Device Feature List (DFL) bus.
>
> A DFHv1 header may have one or more parameter blocks that
> further describes the HW to SW. Add support to the DFL bus
> to parse the MSI-X parameter.
>
> The location of a feature's register set is explicitly
> described in DFHv1 and can be relative to the base of the DFHv1
> or an absolute address. Parse the location and pass the information
> to DFL driver.
...
> v10: change dfh_find_param to return size of parameter data in bytes
The problem that might occur with this approach is byte ordering.
When we have u64 items, we know that they all are placed in CPU
ordering by the bottom layer. What's the contract now? Can it be
a problematic? Please double check this (always keep in mind BE32
as most interesting case for u64/unsigned long representation and
other possible byte ordering outcomes).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v10 4/4] tty: serial: 8250: add DFL bus driver for Altera 16550.
From: Andy Shevchenko @ 2023-01-10 10:32 UTC (permalink / raw)
To: matthew.gerlach
Cc: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal,
trix, mdf, linux-fpga, linux-doc, linux-kernel, tianfei.zhang,
corbet, gregkh, linux-serial, jirislaby, geert+renesas,
niklas.soderlund+renesas, macro, johan, lukas, ilpo.jarvinen,
marpagan, bagasdotme
In-Reply-To: <20230110003029.806022-5-matthew.gerlach@linux.intel.com>
On Mon, Jan 09, 2023 at 04:30:29PM -0800, matthew.gerlach@linux.intel.com wrote:
> From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
>
> Add a Device Feature List (DFL) bus driver for the Altera
> 16550 implementation of UART.
...
> +static int dfh_get_u64_param_val(struct dfl_device *dfl_dev, int param_id, u64 *pval)
> +{
> + size_t psize;
> + u64 *p;
> +
> + p = dfh_find_param(dfl_dev, param_id, &psize);
> + if (IS_ERR(p))
> + return PTR_ERR(p);
> + if (psize != sizeof(u64))
> + return -EINVAL;
If this code stays in the newer versions, make it more robust against changes,
i.e. by using sizeof(*pval).
> + *pval = *p;
> +
> + return 0;
> +}
...
> +config SERIAL_8250_DFL
> + tristate "DFL bus driver for Altera 16550 UART"
5
> + depends on SERIAL_8250 && FPGA_DFL
> + help
> + This option enables support for a Device Feature List (DFL) bus
> + driver for the Altera 16650 UART. One or more Altera 16650 UARTs
6
Which one is correct?
> + can be instantiated in a FPGA and then be discovered during
> + enumeration of the DFL bus.
> +
> + To compile this driver as a module, chose M here: the
> + module will be called 8250_dfl.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 00/13] tty/serial: bool conversions and cleanups
From: Ilpo Järvinen @ 2023-01-10 12:02 UTC (permalink / raw)
To: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Johan Hovold,
Samuel Iglesias Gonsálvez, Rodolfo Giometti
Cc: linux-kernel, Ilpo Järvinen
There are number of functions in tty/serial which have arguments or
return types that expect/behave like bool. Likely due to them existing
before bool was available, other types are used. Make conversions to
bool and cleanups.
v2:
- Call dtr/rts parameters/variables consistently "active"
- Don't chain one return statement with ||
- Don't change function signatures to >80 chars ("while at it")
- moxa: differentiated dtr and status variables
Ilpo Järvinen (13):
tty: Cleanup tty_port_set_initialized() bool parameter
tty: Cleamup tty_port_set_suspended() bool parameter
tty: Cleanup tty_port_set_active() bool parameter
tty: moxa: Make local var storing tty_port_initialized() bool
serial: Convert uart_{,port_}startup() init_hw param to bool
tty: Convert ->carrier_raised() and callchains to bool
tty: Convert ->dtr_rts() to take bool argument
tty/serial: Make ->dcd_change()+uart_handle_dcd_change() status bool
active
serial: Make uart_handle_cts_change() status param bool active
tty: Return bool from tty_termios_hw_change()
tty/serial: Call ->dtr_rts() parameter active consistently
tty: moxa: Rename dtr/rts parameters/variables to active
usb/serial: Rename dtr/rts parameters/variables to active
drivers/char/pcmcia/synclink_cs.c | 18 +++----
drivers/ipack/devices/ipoctal.c | 4 +-
drivers/mmc/core/sdio_uart.c | 13 +++--
drivers/pps/clients/pps-ldisc.c | 6 +--
drivers/s390/char/con3215.c | 4 +-
drivers/staging/greybus/uart.c | 4 +-
drivers/tty/amiserial.c | 12 ++---
drivers/tty/hvc/hvc_console.c | 4 +-
drivers/tty/hvc/hvc_console.h | 2 +-
drivers/tty/hvc/hvc_iucv.c | 6 +--
drivers/tty/moxa.c | 80 ++++++++++++++--------------
drivers/tty/mxser.c | 11 ++--
drivers/tty/n_gsm.c | 16 +++---
drivers/tty/serial/imx.c | 2 +-
drivers/tty/serial/max3100.c | 2 +-
drivers/tty/serial/max310x.c | 3 +-
drivers/tty/serial/serial_core.c | 65 +++++++++++-----------
drivers/tty/serial/sunhv.c | 8 +--
drivers/tty/synclink_gt.c | 21 ++++----
drivers/tty/tty_ioctl.c | 8 +--
drivers/tty/tty_port.c | 22 ++++----
drivers/usb/class/cdc-acm.c | 4 +-
drivers/usb/serial/ch341.c | 11 ++--
drivers/usb/serial/console.c | 2 +-
drivers/usb/serial/cp210x.c | 6 +--
drivers/usb/serial/cypress_m8.c | 6 +--
drivers/usb/serial/digi_acceleport.c | 6 +--
drivers/usb/serial/f81232.c | 10 ++--
drivers/usb/serial/f81534.c | 4 +-
drivers/usb/serial/ftdi_sio.c | 6 +--
drivers/usb/serial/generic.c | 10 ++--
drivers/usb/serial/ipw.c | 8 +--
drivers/usb/serial/keyspan.c | 6 +--
drivers/usb/serial/keyspan_pda.c | 4 +-
drivers/usb/serial/mct_u232.c | 6 +--
drivers/usb/serial/mxuport.c | 4 +-
drivers/usb/serial/pl2303.c | 11 ++--
drivers/usb/serial/quatech2.c | 6 +--
drivers/usb/serial/sierra.c | 6 +--
drivers/usb/serial/spcp8x5.c | 11 ++--
drivers/usb/serial/ssu100.c | 6 +--
drivers/usb/serial/upd78f0730.c | 8 +--
drivers/usb/serial/usb-serial.c | 8 +--
drivers/usb/serial/usb-wwan.h | 2 +-
drivers/usb/serial/usb_wwan.c | 6 +--
drivers/usb/serial/xr_serial.c | 8 +--
include/linux/serial_core.h | 6 +--
include/linux/tty.h | 2 +-
include/linux/tty_ldisc.h | 4 +-
include/linux/tty_port.h | 10 ++--
include/linux/usb/serial.h | 6 +--
net/bluetooth/rfcomm/tty.c | 2 +-
52 files changed, 247 insertions(+), 259 deletions(-)
--
2.30.2
^ permalink raw reply
* [PATCH v2 01/13] tty: Cleanup tty_port_set_initialized() bool parameter
From: Ilpo Järvinen @ 2023-01-10 12:02 UTC (permalink / raw)
To: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Johan Hovold,
Samuel Iglesias Gonsálvez, Rodolfo Giometti, Arnd Bergmann,
Jens Taprogge, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
linux-kernel, industrypack-devel, linux-s390, linux-arm-kernel,
linux-usb
Cc: Ilpo Järvinen
In-Reply-To: <20230110120226.14972-1-ilpo.jarvinen@linux.intel.com>
Make callers pass true/false consistently for bool val.
Reviewed-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/char/pcmcia/synclink_cs.c | 4 ++--
drivers/ipack/devices/ipoctal.c | 4 ++--
drivers/s390/char/con3215.c | 4 ++--
drivers/tty/amiserial.c | 4 ++--
drivers/tty/moxa.c | 2 +-
drivers/tty/mxser.c | 2 +-
drivers/tty/n_gsm.c | 4 ++--
drivers/tty/serial/serial_core.c | 6 +++---
drivers/tty/synclink_gt.c | 4 ++--
drivers/tty/tty_port.c | 4 ++--
drivers/usb/serial/console.c | 2 +-
11 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/char/pcmcia/synclink_cs.c b/drivers/char/pcmcia/synclink_cs.c
index b2735be81ab2..baa46e8a094b 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -1309,7 +1309,7 @@ static int startup(MGSLPC_INFO * info, struct tty_struct *tty)
if (tty)
clear_bit(TTY_IO_ERROR, &tty->flags);
- tty_port_set_initialized(&info->port, 1);
+ tty_port_set_initialized(&info->port, true);
return 0;
}
@@ -1359,7 +1359,7 @@ static void shutdown(MGSLPC_INFO * info, struct tty_struct *tty)
if (tty)
set_bit(TTY_IO_ERROR, &tty->flags);
- tty_port_set_initialized(&info->port, 0);
+ tty_port_set_initialized(&info->port, false);
}
static void mgslpc_program_hw(MGSLPC_INFO *info, struct tty_struct *tty)
diff --git a/drivers/ipack/devices/ipoctal.c b/drivers/ipack/devices/ipoctal.c
index fc00274070b6..103fce0c49e6 100644
--- a/drivers/ipack/devices/ipoctal.c
+++ b/drivers/ipack/devices/ipoctal.c
@@ -647,7 +647,7 @@ static void ipoctal_hangup(struct tty_struct *tty)
tty_port_hangup(&channel->tty_port);
ipoctal_reset_channel(channel);
- tty_port_set_initialized(&channel->tty_port, 0);
+ tty_port_set_initialized(&channel->tty_port, false);
wake_up_interruptible(&channel->tty_port.open_wait);
}
@@ -659,7 +659,7 @@ static void ipoctal_shutdown(struct tty_struct *tty)
return;
ipoctal_reset_channel(channel);
- tty_port_set_initialized(&channel->tty_port, 0);
+ tty_port_set_initialized(&channel->tty_port, false);
}
static void ipoctal_cleanup(struct tty_struct *tty)
diff --git a/drivers/s390/char/con3215.c b/drivers/s390/char/con3215.c
index 72ba83c1bc79..0b05cd76b7d0 100644
--- a/drivers/s390/char/con3215.c
+++ b/drivers/s390/char/con3215.c
@@ -629,7 +629,7 @@ static int raw3215_startup(struct raw3215_info *raw)
if (tty_port_initialized(&raw->port))
return 0;
raw->line_pos = 0;
- tty_port_set_initialized(&raw->port, 1);
+ tty_port_set_initialized(&raw->port, true);
spin_lock_irqsave(get_ccwdev_lock(raw->cdev), flags);
raw3215_try_io(raw);
spin_unlock_irqrestore(get_ccwdev_lock(raw->cdev), flags);
@@ -659,7 +659,7 @@ static void raw3215_shutdown(struct raw3215_info *raw)
spin_lock_irqsave(get_ccwdev_lock(raw->cdev), flags);
remove_wait_queue(&raw->empty_wait, &wait);
set_current_state(TASK_RUNNING);
- tty_port_set_initialized(&raw->port, 1);
+ tty_port_set_initialized(&raw->port, true);
}
spin_unlock_irqrestore(get_ccwdev_lock(raw->cdev), flags);
}
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index f52266766df9..f8cdce1626cb 100644
--- a/drivers/tty/amiserial.c
+++ b/drivers/tty/amiserial.c
@@ -502,7 +502,7 @@ static int startup(struct tty_struct *tty, struct serial_state *info)
*/
change_speed(tty, info, NULL);
- tty_port_set_initialized(port, 1);
+ tty_port_set_initialized(port, true);
local_irq_restore(flags);
return 0;
@@ -556,7 +556,7 @@ static void shutdown(struct tty_struct *tty, struct serial_state *info)
set_bit(TTY_IO_ERROR, &tty->flags);
- tty_port_set_initialized(&info->tport, 0);
+ tty_port_set_initialized(&info->tport, false);
local_irq_restore(flags);
}
diff --git a/drivers/tty/moxa.c b/drivers/tty/moxa.c
index 35b6fddf0341..bc474f3c3f8f 100644
--- a/drivers/tty/moxa.c
+++ b/drivers/tty/moxa.c
@@ -1484,7 +1484,7 @@ static int moxa_open(struct tty_struct *tty, struct file *filp)
MoxaPortLineCtrl(ch, 1, 1);
MoxaPortEnable(ch);
MoxaSetFifo(ch, ch->type == PORT_16550A);
- tty_port_set_initialized(&ch->port, 1);
+ tty_port_set_initialized(&ch->port, true);
}
mutex_unlock(&ch->port.mutex);
mutex_unlock(&moxa_openlock);
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 2436e0b10f9a..2926a831727d 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -1063,7 +1063,7 @@ static int mxser_set_serial_info(struct tty_struct *tty,
} else {
retval = mxser_activate(port, tty);
if (retval == 0)
- tty_port_set_initialized(port, 1);
+ tty_port_set_initialized(port, true);
}
mutex_unlock(&port->mutex);
return retval;
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index daf12132deb1..631539c17d85 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2059,7 +2059,7 @@ static void gsm_dlci_close(struct gsm_dlci *dlci)
tty_port_tty_hangup(&dlci->port, false);
gsm_dlci_clear_queues(dlci->gsm, dlci);
/* Ensure that gsmtty_open() can return. */
- tty_port_set_initialized(&dlci->port, 0);
+ tty_port_set_initialized(&dlci->port, false);
wake_up_interruptible(&dlci->port.open_wait);
} else
dlci->gsm->dead = true;
@@ -3880,7 +3880,7 @@ static int gsmtty_open(struct tty_struct *tty, struct file *filp)
dlci->modem_rx = 0;
/* We could in theory open and close before we wait - eg if we get
a DM straight back. This is ok as that will have caused a hangup */
- tty_port_set_initialized(port, 1);
+ tty_port_set_initialized(port, true);
/* Start sending off SABM messages */
if (gsm->initiator)
gsm_dlci_begin_open(dlci);
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index b9fbbee598b8..e049c760b738 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -290,7 +290,7 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state)
set_bit(TTY_IO_ERROR, &tty->flags);
if (tty_port_initialized(port)) {
- tty_port_set_initialized(port, 0);
+ tty_port_set_initialized(port, false);
/*
* Turn off DTR and RTS early.
@@ -2347,7 +2347,7 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
unsigned int mctrl;
tty_port_set_suspended(port, 1);
- tty_port_set_initialized(port, 0);
+ tty_port_set_initialized(port, false);
spin_lock_irq(&uport->lock);
ops->stop_tx(uport);
@@ -2458,7 +2458,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
uart_rs485_config(uport);
ops->start_tx(uport);
spin_unlock_irq(&uport->lock);
- tty_port_set_initialized(port, 1);
+ tty_port_set_initialized(port, true);
} else {
/*
* Failed to resume - maybe hardware went away?
diff --git a/drivers/tty/synclink_gt.c b/drivers/tty/synclink_gt.c
index 72b76cdde534..2b96bf0ecafb 100644
--- a/drivers/tty/synclink_gt.c
+++ b/drivers/tty/synclink_gt.c
@@ -2354,7 +2354,7 @@ static int startup(struct slgt_info *info)
if (info->port.tty)
clear_bit(TTY_IO_ERROR, &info->port.tty->flags);
- tty_port_set_initialized(&info->port, 1);
+ tty_port_set_initialized(&info->port, true);
return 0;
}
@@ -2401,7 +2401,7 @@ static void shutdown(struct slgt_info *info)
if (info->port.tty)
set_bit(TTY_IO_ERROR, &info->port.tty->flags);
- tty_port_set_initialized(&info->port, 0);
+ tty_port_set_initialized(&info->port, false);
}
static void program_hw(struct slgt_info *info)
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index dce08a6d7b5e..0c00d5bd6c88 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -367,7 +367,7 @@ static void tty_port_shutdown(struct tty_port *port, struct tty_struct *tty)
goto out;
if (tty_port_initialized(port)) {
- tty_port_set_initialized(port, 0);
+ tty_port_set_initialized(port, false);
/*
* Drop DTR/RTS if HUPCL is set. This causes any attached
* modem to hang up the line.
@@ -788,7 +788,7 @@ int tty_port_open(struct tty_port *port, struct tty_struct *tty,
return retval;
}
}
- tty_port_set_initialized(port, 1);
+ tty_port_set_initialized(port, true);
}
mutex_unlock(&port->mutex);
return tty_port_block_til_ready(port, tty, filp);
diff --git a/drivers/usb/serial/console.c b/drivers/usb/serial/console.c
index da19a5fa414f..c3ea3a46ed76 100644
--- a/drivers/usb/serial/console.c
+++ b/drivers/usb/serial/console.c
@@ -169,7 +169,7 @@ static int usb_console_setup(struct console *co, char *options)
tty_save_termios(tty);
tty_kref_put(tty);
}
- tty_port_set_initialized(&port->port, 1);
+ tty_port_set_initialized(&port->port, true);
}
/* Now that any required fake tty operations are completed restore
* the tty port count */
--
2.30.2
^ permalink raw reply related
* [PATCH v2 02/13] tty: Cleamup tty_port_set_suspended() bool parameter
From: Ilpo Järvinen @ 2023-01-10 12:02 UTC (permalink / raw)
To: linux-serial, Greg Kroah-Hartman, Jiri Slaby, Johan Hovold,
Samuel Iglesias Gonsálvez, Rodolfo Giometti, linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20230110120226.14972-1-ilpo.jarvinen@linux.intel.com>
Make callers pass true/false consistently for bool val.
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/tty/serial/serial_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index e049c760b738..f9564b1e3dfb 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -312,7 +312,7 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state)
* a DCD drop (hangup) at just the right time. Clear suspended bit so
* we don't try to resume a port that has been shutdown.
*/
- tty_port_set_suspended(port, 0);
+ tty_port_set_suspended(port, false);
/*
* Do not free() the transmit buffer page under the port lock since
@@ -1725,7 +1725,7 @@ static void uart_tty_port_shutdown(struct tty_port *port)
* a DCD drop (hangup) at just the right time. Clear suspended bit so
* we don't try to resume a port that has been shutdown.
*/
- tty_port_set_suspended(port, 0);
+ tty_port_set_suspended(port, false);
/*
* Free the transmit buffer.
@@ -2346,7 +2346,7 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
int tries;
unsigned int mctrl;
- tty_port_set_suspended(port, 1);
+ tty_port_set_suspended(port, true);
tty_port_set_initialized(port, false);
spin_lock_irq(&uport->lock);
@@ -2469,7 +2469,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
}
}
- tty_port_set_suspended(port, 0);
+ tty_port_set_suspended(port, false);
}
mutex_unlock(&port->mutex);
--
2.30.2
^ 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