On Sunday 17 May 2020 17:57:02 Gregory CLEMENT wrote:
> Hello,
>
> > Hello,
> >
> > On Thu, 30 Apr 2020 10:06:13 +0200
> > Pali Rohár wrote:
> >
> >> Marek Behún (5):
> >> PCI: aardvark: Improve link training
> >> PCI: aardvark:
On Saturday 16 May 2020 08:17:17 Ganapathi Bhat wrote:
> Hi Pali,
>
> Thanks for this notice. We will try to push the new firmware and also, fix
> the naming problem.
>
> Regards,
> Ganapathi
Thank you! Please consider extending kernel driver to load firmware
from filename sdsd8997_combo_v4.bin
Hello!
There is inconsistency in firmware naming for W8997 SDIO wifi chip.
Firmware for this chip is stored in linux-firmware [1] repository under
filename sdsd8997_combo_v4.bin.
But mainline linux kernel driver mwifiex_sdio.ko [2] expects and loads
firmware for this chip from filename sd8997_ua
just be an array). Such a change
may be proposed in the future. In the meantime this patch can backported
into stable kernels in this simple form.
Fixes: 8baca1a34d4c ("mwifiex: dump station support in uap mode")
Signed-off-by: Pali Rohár
---
drivers/net/wireless/marvell/mwifiex/cfg80
27;t see in dmesg.
>
> Signed-off-by: Koba Ko
Fine for me, you can add:
Reviewed-by: Pali Rohár
Darren / Andy, when applying this patch, please add Fixes line so this
change would be propagated to stable kernels:
Fixes: d00fa46e0a2c6 ("platform/x86: dell-laptop: Add micmute LED trig
On Wednesday 13 May 2020 12:33:14 Lorenzo Pieralisi wrote:
> On Wed, May 13, 2020 at 01:16:51PM +0200, Pali Rohár wrote:
> > On Thursday 30 April 2020 10:06:13 Pali Rohár wrote:
> > > Hello,
> > >
> > > this is the fourth version of the patch series for Armada
On Thursday 30 April 2020 10:06:13 Pali Rohár wrote:
> Hello,
>
> this is the fourth version of the patch series for Armada 3720 PCIe
> controller (aardvark). It's main purpose is to fix some bugs regarding
> buggy ath10k cards, but we also found out some suspicious stuff ab
On Friday 08 May 2020 22:59:57 Thomas Gleixner wrote:
> Pali,
>
> Pali Rohár writes:
>
> > I'm looking at clocks which are provided by kernel for userspace
> > applications via clock_gettime() syscall and I think that there is
> > missing clock variant CLOCK
Hello Thomas!
I'm looking at clocks which are provided by kernel for userspace
applications via clock_gettime() syscall and I think that there is
missing clock variant CLOCK_BOOTTIME_RAW.
If userspace application wants to measure time difference between two
events then I think all of available cl
Correct name of constant is CLOCK_BOOTTIME and not CLOCK_BOOTIME.
Signed-off-by: Pali Rohár
---
drivers/net/wireless/intel/ipw2x00/ipw2200.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.h
b/drivers/net/wireless/intel/ipw2x00
On Thursday 07 May 2020 15:54:06 Andy Shevchenko wrote:
> On Thu, May 7, 2020 at 2:45 PM Pali Rohár wrote:
> > On Thursday 07 May 2020 19:27:47 Koba Ko wrote:
>
> > > don't understand "registration and deregistration would be optional',
> > > coul
called when there is no
device registered.
> I will modify the comment of patch.
>
> On Thu, May 7, 2020 at 7:13 PM Pali Rohár wrote:
>
> > On Thursday 07 May 2020 17:42:42 koba...@canonical.com wrote:
> > > From: Koba Ko
> > >
> > > Error messge is
On Thursday 07 May 2020 17:42:42 koba...@canonical.com wrote:
> From: Koba Ko
>
> Error messge is issued,
> "platform::micmute: Setting an LED's brightness failed (-19)",
> Even the device isn't presented.
>
> Get the related tokens of SMBIOS, GLOBAL_MIC_MUTE_DISABLE/ENABLE.
> If one of two toke
Hello!
On Tuesday 05 May 2020 12:57:37 Joe Perches wrote:
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index eac40f0abd56a9f4..3355358697d9e790 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -1057,6 +1057,10 @@ for my $filename (@ARGV) {
> >
On Monday 27 January 2020 12:24:28 Sascha Hauer wrote:
> On Mon, Jan 27, 2020 at 12:16:30PM +0100, Pali Rohár wrote:
> > On Monday 06 January 2020 09:16:05 Sascha Hauer wrote:
> > > On Wed, Dec 25, 2019 at 07:18:40PM +0100, Pali Rohár wrote:
> > > > Hello Sascha!
On Friday 01 May 2020 22:30:27 Arnd Bergmann wrote:
> On Thu, Apr 30, 2020 at 11:54 PM Pali Rohár wrote:
> >
> > On Thursday 30 April 2020 23:30:51 Arnd Bergmann wrote:
> > > gcc-10 warns about writes to the empty freeSpaceTable[] array, with
> > > many instances
On Thursday 30 April 2020 23:30:51 Arnd Bergmann wrote:
> gcc-10 warns about writes to the empty freeSpaceTable[] array, with
> many instances like:
>
> fs/udf/balloc.c: In function 'udf_bitmap_new_block':
> fs/udf/balloc.c:101:36: error: array subscript 65535 is outside the bounds of
> an interi
On Thursday 30 April 2020 10:06:18 Pali Rohár wrote:
> +static void advk_pcie_issue_perst(struct advk_pcie *pcie)
> +{
> + u32 reg;
> +
> + if (!pcie->reset_gpio)
> + return;
> +
> + /* PERST does not work for some cards when link trainin
ned-off-by: Pali Rohár
---
drivers/pci/controller/pci-aardvark.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index f9955b494267..74b90940a9d4 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/d
k training.
Tested on Turris MOX.
Signed-off-by: Pali Rohár
---
drivers/pci/controller/pci-aardvark.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index e202f954eb84..2e
: Describe new properties
arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function
arm64: dts: marvell: armada-37xx: Move PCIe comphy handle property
Pali Rohár (7):
PCI: aardvark: Train link immediately after enabling training
PCI: aardvark: Don't blindly enable ASPM L0s an
From: Marek Behún
We found out that we are unable to control the PERST# signal via the
default pin dedicated to be PERST# pin (GPIO2[3] pin) on A3700 SOC when
this pin is in EP_PCIE1_Resetn mode. There is a register in the PCIe
register space called PERSTN_GPIO_EN (D0088004[3]), but changing the
From: Marek Behún
With recent proposed changes for U-Boot it is possible that bootloader
won't initialize the PHY for this controller (currently the PHY is
initialized regardless whether PCI is used in U-Boot, but with these
proposed changes the PHY is initialized only on request).
Since the mve
From: Marek Behún
Move the comphy handle property of the PCIe node from board specific
device tree files (EspressoBin and Turris Mox) to the generic
armada-37xx.dtsi.
This is correct since this is the only possible PCIe PHY configuration
on Armada 37xx, so when PCIe is enabled on any board, this
Move the max-link-speed property of the PCIe node from board specific
device tree files to the generic armada-37xx.dtsi.
Armada 37xx supports only PCIe gen2 speed so max-link-speed property
should be in the genetic armada-37xx.dtsi file.
Signed-off-by: Pali Rohár
---
arch/arm64/boot/dts
ng at this mode or lower until successful. After successful
link training choose final controller gen based on Negotiated Link Speed
from Link Status register, which should match card speed.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
---
drivers/pci/controller/pci-aardva
investigated and a comment explaining this should be put
before the code, so we add a FIXME comment for now.
Signed-off-by: Pali Rohár
---
drivers/pci/controller/pci-aardvark.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci
Interpret zero value of max-link-speed property as invalid,
as the device tree bindings documentation specifies.
Signed-off-by: Pali Rohár
---
drivers/pci/of.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 81ceeaa6f1d5
From: Marek Behún
Document the possibility to reference a PHY and reset-gpios and to set
max-link-speed property.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/pci/aardvark-pci.txt | 4
1 file changed, 4 insertions(+)
dif
issues of Compex WLE900VX card on Turris MOX after
cold boot.
Fixes: f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...")
Signed-off-by: Pali Rohár
---
drivers/pci/controller/pci-aardvark.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/d
PCI-E capability macros are already defined in linux/pci_regs.h.
Remove their reimplementation in pcie-aardvark.
Signed-off-by: Pali Rohár
---
drivers/pci/controller/pci-aardvark.c | 41 ---
1 file changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/pci
On Monday 27 April 2020 11:49:13 Sasha Levin wrote:
> On Tue, Apr 21, 2020 at 11:30:45PM +0200, Pali Rohár wrote:
> > On Thursday 13 February 2020 16:18:47 Sasha Levin wrote:
> > > On Thu, Feb 13, 2020 at 01:06:56AM +0100, Pali Rohár wrote:
> > > > In released exFA
, second
thing described in their FAT implementation and thing thing is how it is
really implemented (in fatfast.sys kernel driver which is open source).
So I would be really careful about how MS's exfat.sys implementation is
working.
--
Pali Rohár
pali.ro...@gmail.com
On Monday 21 October 2019 13:08:07 Maurizio Lombardi wrote:
> Dne 21.10.2019 v 12:54 Pali Rohár napsal(a):
> > Plus there is new version of
> > this out-of-tree Samsung's exfat driver called sdfat which can be found
> > in some Android phones.
>
> [...]
>
>
inits internal info from on-disk boot sector*/
> +static int exfat_init_from_boot(struct super_block *sb, struct exfat_boot
> *boot,
> + u64 bytes_per_volume, u32 *root_lcn)
> +{
...
> + if (boot->fats != 1) {
> + hint = &
t this
Konstantin's implementation is more closer then one in staging to be
"primary" exfat implementation for kernel (if write support would be
provided).
[1] - https://github.com/cryptomilk/kernel-sdfat
[2] - https://github.com/relan/exfat
[3] - https://www.tuxera.com/products/tuxer
; },
> + { Opt_utf8_yes, "utf8=true" },
> + { Opt_utf8_yes, "utf8" },
There are lot of utf8 mount options. Are they really needed?
Would not it be better to use just one "iocharset" mount option like
other Unicode based filesystem have it (e.g. vfat, j
s
first. And all operations are done on Secondary FAT and then is
Secondary FAT copied to Primary. This is backward compatible with
systems which operates only with first primary FAT. And other systems
which see both FATs can benefit from redundancy/recovery.
--
Pali Rohár
pali.ro...@gmail.com
On Wednesday 16 October 2019 16:33:17 Sasha Levin wrote:
> On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> > > On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> > > > On Friday 30 A
On Wednesday 16 October 2019 09:22:11 Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > > Can I assume you will be implementing TexFAT support once the spec is
> > > available?
> >
> > I cannot promise that I would implem
On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> > On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> > > On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > > > With regards to missing
On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > With regards to missing specs/docs/whatever - our main concern with this
> > release was that we want full interoperability, which is why the spec
> > was made
or update! Now it is clear what is the problem
and you can add my
Reviewed-by: Pali Rohár
> drivers/platform/x86/dell-laptop.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/platform/x86/dell-laptop.c
> b/drivers/platform/x86/de
DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 1018"),
> > + },
> > + .driver_data = &quirk_dell_inspiron_1012,
> > + },
> > { }
> > };
> >
> > @@ -2040,6 +2063,9 @@ static int __init kbd_led_init(struct device *dev)
> > {
> > int ret;
> >
> > + if (quirks && quirks->kbd_broken_backlight)
> > + return -ENODEV;
> > +
> > kbd_init();
> > if (!kbd_led_present)
> > return -ENODEV;
> > --
> > 2.19.2
>
>
>
--
Pali Rohár
pali.ro...@gmail.com
On Wednesday 25 September 2019 11:07:35 Andy Shevchenko wrote:
> On Mon, Sep 23, 2019 at 4:24 PM wrote:
> > > From: Pali Rohár
> > > Sent: Sunday, September 22, 2019 8:43 AM
> > > To: Pacien TRAN-GIRARD
> > > Cc: Matthew Garrett; Darren Hart; An
On Wednesday 18 September 2019 17:29:15 Pacien TRAN-GIRARD wrote:
> Quoting Pali Rohár (2019-09-12 09:33:58)
> > On Thursday 12 September 2019 01:14:48 Pacien TRAN-GIRARD wrote:
> > > This patch registers a quirk disabling keyboard backlight support
> > > for the
. Have you already reported it to Dell?
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107651
> Signed-off-by: Pacien TRAN-GIRARD
--
Pali Rohár
pali.ro...@gmail.com
e the rng either.
Probably this is the reason, you do not have crypto/rng HW engine.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
nicating
> with the security middleware component instead of directly accessing
> the RNG hardware.
And that component is loaded by signed bootloader into "secure" area not
accessible by "non-secure" work (like kernel) and communication is done
via arm smc instruction.
--
Pali Rohár
pali.ro...@gmail.com
reg = <0x0 0x2000>;
> > > + interrupts = <52>;
> > > + };
> > > + };
> > > +
>
> I applied this on 5.3 and it is working. I assume the same is true in
> for-next.
>
> Do you want to submit a formal patch? I can mark it as 'tested-by'
> This really helps speed up the startup sequence on boards with sshd
> because it delays for nearly 80 seconds waiting for entropy without
> the hwrng.
Hi! When applying a patch, could you please disable this rng for n900?
In omap3-n900.dts for rng should be status = "disabled" (as Tony already
wrote), similarly like for aes.
Thanks!
> adam
> >
> > Tony,
> >
> > Can you tell me what branch you're using? I am not seeing the note
> > below, so I am not exactly sure what version to base my testing.
> >
> > ada,
> > > /*
> > > * Note that the sysconfig register layout is a subset of
> > > the
> > > * "ti,sysc-omap4" type register with just sidle and
> > > midle bits
--
Pali Rohár
pali.ro...@gmail.com
_.
>
> https://lore.kernel.org/lkml/20190821174857.GD76194@dtor-ws/
>
> So please no.
Dmitry and I already rejected this patch, see also linked-list:
https://lore.kernel.org/lkml/20190820111719.7blyk5jstgwde2ae@pali/
> >
> > Signed-off-by: Denis Efremov
> > C
On Friday 30 August 2019 08:40:06 Christoph Hellwig wrote:
> On Thu, Aug 29, 2019 at 10:56:31PM +0200, Pali Rohár wrote:
> > In my opinion, proper way should be to implement exFAT support into
> > existing fs/fat/ code instead of replacing whole vfat/msdosfs by this
> >
ive merits
... but is this advantage such big that it should be merged even due to
"horrible" code quality and lot of code/functionality duplication?
In similar way there should be discussion about these pros and cons.
--
Pali Rohár
pali.ro...@gmail.com
e labels and I found more bugs in current implementations
(mtools, dosfstools, util-linux and even in fastfat.sys). Some
references are on: https://www.spinics.net/lists/kernel/msg2640891.html
Fixes for mtools, dosfstools and util-linux were already applied and fix
for MS's fastfat.sys is pending in opened pull request:
https://github.com/microsoft/Windows-driver-samples/pull/303
Could you please forward my pull request for fastfat.sys fixes to
appropriate people/team in MS?
--
Pali Rohár
pali.ro...@gmail.com
do not need two different implementation of
VFAT32.
So I'm a bit sceptical about usefulness of this exfat code/driver, if it
makes any sense to have it even in staging.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
value is only valid
> > for
> > TexFAT volumes
>
> I think we're OK if we just set ActiveFat to 0 and NumberOfFats to 1.
But this degrades whole FS. Even FAT32 uses two FAT tables due to big
factor of brokenness and fsck takes care of it when repairing.
There is not too much sense to use exFAT with just one FAT if we have
already working FAT32 with redundancy of FAT table.
> Unless somebody has actual evidence of a non-WindowsCE extfat that has
> NumberOfFats == 2
--
Pali Rohár
pali.ro...@gmail.com
xistence of such documentation until
somebody implement it and do some testing against MS own implementation.
--
Pali Rohár
pali.ro...@gmail.com
On Tuesday 20 August 2019 14:21:33 Enrico Weigelt, metux IT consult wrote:
> On 20.08.19 13:17, Pali Rohár wrote:
> > On Tuesday 20 August 2019 12:56:12 Enrico Weigelt, metux IT consult wrote:
> > > From: Enrico Weigelt
> > >
> > > IS_ERR() already calls unlik
On Tuesday 20 August 2019 15:56:24 Sebastian Duda wrote:
> On 20.08.19 15:14, Pali Rohár wrote:
> > On Tuesday 20 August 2019 15:05:51 Sebastian Duda wrote:
> > > Hello Pali,
> > >
> > > in my master thesis, I'm using the association of subsystems to
&
bastian Duda
Hi Sebastian! ALPS PS/2 is a driver for ALPS touchpad. They can be
found on more laptops. And ALPS PS/2 itself is not separate subsystem.
It is just driver which is part of kernel input subsystem with mailing
list linux-in...@vger.kernel.org.
--
Pali Rohár
pali.ro...@gmail.com
_ERR_OR_NULL(priv->dev3)) {
> /* Register dev3 mouse if we received PS/2 packet first time */
> if (!IS_ERR(priv->dev3))
> psmouse_queue_work(psmouse, &priv->dev3_register_work,
Hello! Two months ago I already saw th
On Tuesday 13 August 2019 09:13:58 Denis Efremov wrote:
> Update MAINTAINERS to reflect that isp1704_charger.h file was removed.
>
> Cc: Linus Walleij
> Cc: Pavel Machek
> Cc: Pali Rohár
> Cc: Sebastian Reichel
> Cc: linux...@vger.kernel.org
> Fixes: f5d782d46aa5
used block. IIRC in this case kernel just fallback to the last
block of block device for VAT, which in this case is not correct.
What should help is to truncate image file to "correct" size after
running mkudffs with --media-type=cdr. Maybe mkudffs itself should do it
when was asked to create UDF filesystem for CD-R on existing image file.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
On Thursday 01 August 2019 09:35:30 Jan Kara wrote:
> On Fri 12-07-19 12:02:24, Pali Rohár wrote:
> > Also in git master of udftools has mkduffs now new option --read-only
> > which creates UDF image with Read-Only Access Type.
>
> I've tested this and the kernel prop
treat also filesystem with VAT as read-only too.
--
Pali Rohár
pali.ro...@gmail.com
gt; + else if (!strncmp(vsd->stdIdent, VSD_STD_ID_BOOT2, VSD_STD_ID_LEN))
> + ; /* vsd_id = 0 */
> + else if (!strncmp(vsd->stdIdent, VSD_STD_ID_CDW02, VSD_STD_ID_LEN))
> + ; /* vsd_id = 0 */
> + else {
> + /* TEA01 or invalid id : end of volume recognition area */
> + vsd_id = 255;
> + }
> +
> + return vsd_id;
> +}
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
On Wednesday 10 July 2019 08:24:09 Steve Magnani wrote:
>
> On 7/9/19 4:04 PM, Pali Rohár wrote:
> > On Tuesday 09 July 2019 15:14:38 Steve Magnani wrote:
> > > On 7/9/19 1:56 PM, Pali Rohár wrote:
> > > > Can grub2 recognize such disks?
> > > I'm
On Tuesday 09 July 2019 15:14:38 Steve Magnani wrote:
>
> On 7/9/19 1:56 PM, Pali Rohár wrote:
> > Steve, can you describe what you mean by Advanced Format 4K sector size?
> >
> > It is hard disk with 512 bytes logical sector size and 4096 bytes
> > physical sector
ously the best solution would be for the Windows bugs to
> get fixed. If anyone reading this can convey these details into
> the Microsoft silo, that would be great.
For Windows 10 users, the only option is to report bug via
Use Feedback app on the Start Menu.
> Regards,
>
> Steven J. Magnani "I claim this network for MARS!
> www.digidescorp.com Earthling, return my space modulator!"
>
> #include
>
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
.
> So alps.c is no need for CS19 device.
So if trackpoint.c driver is working fine with this configuration, it is
just needed to instruct alps.c to not take this device.
> Best Regards
> Shona
> -邮件原件-
> 发件人: Pali Rohár
> 发送时间: Wednesday, June 12, 2019 1:39 A
ch pull request passed compilation and 'make check'.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
On Friday 14 June 2019 07:30:52 Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 04:25:34PM +0200, Pali Rohár wrote:
> > > Does the project already have a maillist ?
> >
> > No, there is no mailing list. Basically whole development is on github
> > via github pu
On Friday 14 June 2019 16:20:08 Enrico Weigelt, metux IT consult wrote:
> On 14.06.19 12:25, Pali Rohár wrote:
> > Hello!
> >
> > Can somebody help with reviewing existing patches / pull requests for
> > dosfstools project? https://github.com/dosfstools/dosfstools/pul
with reviewing
them?
--
Pali Rohár
pali.ro...@gmail.com
On Wednesday 12 June 2019 14:36:04 Greg Kroah-Hartman wrote:
> On Wed, Jun 12, 2019 at 02:21:05PM +0200, Pali Rohár wrote:
> > On Wednesday 12 June 2019 14:12:53 Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, there is no need to ever check the
> > > retu
On Wednesday 12 June 2019 14:12:53 Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Matthew Garrett
&g
On Tuesday 11 June 2019 17:59:13 Dmitry Torokhov wrote:
> Hi Joe,
>
> On Wed, Jun 05, 2019 at 07:28:53PM -0700, Joe Perches wrote:
> > On Thu, 2019-06-06 at 09:08 +0800, Kefeng Wang wrote:
> > > On 2019/6/5 22:42, Pali Rohár wrote:
> > > > On Wednesday 05
On Tuesday 11 June 2019 10:32:28 dmitry.torok...@gmail.com wrote:
> On Tue, Jun 11, 2019 at 07:17:07PM +0200, Pali Rohár wrote:
> > On Tuesday 11 June 2019 10:07:07 dmitry.torok...@gmail.com wrote:
> > > On Tue, Jun 11, 2019 at 09:23:33AM +0200, Pali Rohár wrote:
> > > &
On Tuesday 11 June 2019 10:07:07 dmitry.torok...@gmail.com wrote:
> On Tue, Jun 11, 2019 at 09:23:33AM +0200, Pali Rohár wrote:
> > On Tuesday 11 June 2019 12:32:33 Hui Wang wrote:
> > > On 2019/6/11 上午11:23, Hui Wang wrote:
> > > > On 2019/6/11 上午11:05, Xiaoxia
S
in alps.c and disallow its usage.
Or maybe better, move trackpoint.c detect code before alsp.c detect code
in psmouse-base. And no changes in alps.c are needed.
> > Regards,
> >
> > Hui.
> >
> > >
> > > Best Regards
> > > Shona
> > > -邮件原件-
ne. Just make sure that touchapad input device is not
registered when this ALPS_ONLY_TRACKSTICK flag is set. So userspace
would not see any fake/unavailable touchpad input device.
> Xiaoxiao.Liu
--
Pali Rohár
pali.ro...@gmail.com
on to
conflict with PCI BAR") allowed to use i2c-i801 driver on Dell machines so
lis3lv02d correctly initialize accelerometer.
Tested on Dell Latitude E6440.
Signed-off-by: Pali Rohár
---
Changes since v4:
* Remove usage of redundant acpi_bus_get_status_handle()
* Update com
Hi!
On Thursday 06 June 2019 16:53:09 Jean Delvare wrote:
> Hi Pali,
>
> On Wed, 5 Jun 2019 00:33:03 +0200, Pali Rohár wrote:
> > Dell platform team told us that some (DMI whitelisted) Dell Latitude
> > machines have ST microelectronics accelerometer at I2C address 0x29.
On Wednesday 05 June 2019 22:24:28 Kefeng Wang wrote:
> IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag,
> so no need to do that again from its callers. Drop it.
Hi! I already reviewed this patch and rejected it, see:
https://patchwork.kernel.org/patch/10817475/
&
on to
conflict with PCI BAR") allowed to use i2c-i801 driver on Dell machines so
lis3lv02d correctly initialize accelerometer.
Tested on Dell Latitude E6440.
Signed-off-by: Pali Rohár
---
Changes since v3:
* Use char * [] type for list of acpi ids
* Check that SMO88xx acpi device is presen
Hi!
On Tuesday 04 June 2019 16:57:29 Jean Delvare wrote:
> Hi Pali,
>
> Next time, please start a new thread for a new version of a patch.
Ok!
> On Sun, 2 Jun 2019 15:20:03 +0200, Pali Rohár wrote:
> > Dell platform team told us that some (DMI whitelisted) Dell Latitude
&g
on to
conflict with PCI BAR") allowed to use i2c-i801 driver on Dell machines so
lis3lv02d correctly initialize accelerometer.
Tested on Dell Latitude E6440.
Signed-off-by: Pali Rohár
---
Changes since v2:
* Use explicit list of SMOxx ACPI devices
Changes since v1:
* Added Dell Vostro V13
On Tuesday 28 May 2019 11:50:15 Jean Delvare wrote:
> On Tue, 2019-05-28 at 11:41 +0200, Pali Rohár wrote:
> > This is not a problem. lis3lv02d provides two things:
> >
> > 1) 3 axes accelerometer
> > 2) optional interrupt and signal it to userspace via misc device
>
le. It just
provides for userspace same misc device API as lis3lv02d.
As lis3lv02d has misc device optional, registered i2c device from
i2c-i801 does not enable it.
So technically it is one device, but their functionality divided into
two modules. One which reports accelerometer axes and one which si
rently kernel exports following names when device has both
trackstick and touchpad: "DualPoint Stick" and "DualPoint TouchPad".
And it exports name "GlidePoint" for touchpad-only device. So to be
consistent you need to also modify this code for trackstick-only device.
--
Pali Rohár
pali.ro...@gmail.com
t; - if (reg_val == 0x0C || reg_val == 0x1D)
> + if (reg_val == 0x0C || reg_val == 0x1D) {
Hm... why your device does not match these constants?
> + is_dual = true;
> + } else if (alps_check_cs19_trackstick(psmouse) == 0) {
> + //For support Thinkpad CS19 TrackStick
> is_dual = true;
> + }
> }
> }
>
--
Pali Rohár
pali.ro...@gmail.com
On Friday 24 May 2019 19:32:38 Peter Hutterer wrote:
> On Fri, May 24, 2019 at 09:26:48AM +0200, Pali Rohár wrote:
> > On Friday 24 May 2019 13:50:53 Hui Wang wrote:
> > > On 2019/5/24 下午1:36, Peter Hutterer wrote:
> > > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui
On Friday 24 May 2019 13:50:53 Hui Wang wrote:
> On 2019/5/24 下午1:36, Peter Hutterer wrote:
> > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
> > > On 2019/5/23 下午2:01, Peter Hutterer wrote:
> > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wr
force bare
PS/2 relative mode?
--
Pali Rohár
pali.ro...@gmail.com
asier to understand.
Anyway, more information should be in commit message.
> Best Regards
> XiaoXiao Liu
> sliuuxiaonx...@gmail.com
> xiaoxiao.li...@cn.alps.com
>
> -邮件原件-
> 发件人: Pali Rohár
> 发送时间: Tuesday, May 21, 2019 5:46 PM
> 收件人: Hui Wang
> 抄送: 劉 曉曉 Xiaoxiao
Hello!
On Tuesday 21 May 2019 10:26:47 Hui Wang wrote:
> Tested-by: Hui Wang
>
> On 2019/5/21 上午9:07, Xiaoxiao Liu wrote:
> > Add Pali Rohár.
> >
> > -邮件原件-
> > 发件人: XiaoXiao Liu
> > 发送时间: Monday, May 20, 2019 7:02 PM
> > 收件
On Wednesday 18 April 2018 13:46:10 Pali Rohár wrote:
> On Thursday 08 March 2018 23:53:30 Pali Rohár wrote:
> > On Monday 26 February 2018 21:32:55 Wolfram Sang wrote:
> > >
> > > > I'm not maintainer of i2c-i801.ko, Jean Delvare & Wolfram Sang ar
>
> Signed-off-by: Krzysztof Kozlowski
Ok, you can add my
Reviewed-by: Pali Rohár
> ---
>
> Changes since v1:
> 1. Remove unneeded backslash (pointed by Pali).
> ---
> drivers/power/supply/bq27xxx_battery.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
(di->cache.flags != cache.flags))
> power_supply_changed(di->bat);
>
> if (memcmp(&di->cache, &cache, sizeof(cache)) != 0)
--
Pali Rohár
pali.ro...@gmail.com
On Monday 08 April 2019 20:04:22 Pavel Machek wrote:
> On Mon 2019-04-01 12:24:34, Pali Rohár wrote:
> > Every EFI binary is in PE format. And we know that PE format needs to have
> > MZ MS-DOS header as there is written offset to PE header.
> >
> > Therefore ge
401 - 500 of 1862 matches
Mail list logo
