lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 Apr 2020 17:38:57 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Jiada Wang <jiada_wang@...tor.com>, nick@...anahar.org,
        dmitry.torokhov@...il.com, jikos@...nel.org,
        benjamin.tissoires@...hat.com, bsz@...ihalf.com
Cc:     linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        erosca@...adit-jv.com, Andrew_Gabbasov@...tor.com
Subject: Re: [PATCH v10 43/55] dt-bindings: input: atmel: support to set max
 bytes transferred

31.03.2020 13:50, Jiada Wang пишет:
> Add support to set max bytes transferred in an i2c transaction
> 
> Signed-off-by: Jiada Wang <jiada_wang@...tor.com>
> ---
>  Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> index 126266891cdc..37a798cab0dd 100644
> --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> @@ -45,6 +45,8 @@ Optional properties for main touchpad device:
>  
>  - atmel,input_name: Override name of input device from the default.
>  
> +- atmel,mtu: Maximum number of bytes that can read/transferred in an i2c transaction
> +
>  Example:
>  
>  	touch@4b {
> @@ -52,4 +54,5 @@ Example:
>  		reg = <0x4b>;
>  		interrupt-parent = <&gpio>;
>  		interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW>;
> +		atmel,mtu = <200>
>  	};
> 

Is this a software (firmware) limitation which varies from version to
version?

If the limitation is per-hardware version, then perhaps should be better
to have a hardcoded per-hardware table of limits in the driver?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ