13:26 <ukleinek> broonie: would you consider spi-mux working currently? I'm on v5.13 and see: https://paste.debian.net/1204888/

13:29 <geertu> ukleinek: His only way out would be a systemd joke ;-)

13:34 <ukleinek> geertu: looking at spi_add_device() I'm willing to bet it is not a problem in systemd

14:15 <broonie> ukleinek: I have no idea, I've never seen a system that might need it.

14:19 <mkl_> hey scosu

14:22 <broonie> ukleinek: Nobody else reported any issues, I guess they might have some different ordering WRT when drivers are registered?

15:43 <scosu> hi mkl_

16:32 <ukleinek> broonie: ah, it might work with spi-mux as module ...

16:32 <ukleinek> scosu: hey, long time no read

16:44 <scosu> ukleinek: true, and long time no see ;)

16:45 <broonie> ukleinek: In any case, it does look like a bug.

16:47 <marex> ukleinek: spi mux has its share of issues

16:47 <ukleinek> broonie: I guess the problem started to appear with ddf75be47ca748f8b12d28ac64d624354fddf189

16:47 <broonie> Proably.

16:48 <marex> ukleinek: just out of curiosity, how is your spi mux wired exactly ?

16:49 <marex> ukleinek: I recall that if you had GPIO expander on SPI nCS0 , which controlled the mux , things were rather juicy

16:51 <marex> sboyd_: hey, is there some way to specify, in DT, that I want clock to be kept enabled all the time at specific frequency (say a soc clock which are output on a pin, but have no consumer except for some external gizmo) ? I can imagine assigned-clock-rates is the frequency part, but what about the "keep the clock enabled" part ?

16:51 <marex> I think I am looking for something like gpio-hog, except for clock

16:52 <ukleinek> marex: the setup is pretty much Documentation/devicetree/bindings/spi/spi-mux.yaml, for now (i.e. prototype phase) with a single GPIO

16:53 <ukleinek> marex: what is juicy?

16:53 <ukleinek> marex: different problem than https://paste.debian.net/1204888/ ?

16:53 <marex> ukleinek: last time I tried, it was full of locking issues

16:54 <ukleinek> marex: there is a locking issue, the one I identified is recursive use of spi_add_lock

16:54 <marex> ukleinek: what is controlling your mux ?

16:55 <marex> ukleinek: soc gpio or spi gpio expander ?

16:55 <ukleinek> soc gpio

16:55 <marex> oh, then that should be no problem

17:02 <marex> ukleinek: it is juicy :)

17:04 <ukleinek> marex: the motivation to use a spi-mux is that the imx8 has only one native CS and the native CS is useful in this scenario because we need CS_WORD

20:37 <ukleinek> broonie, marex: I reverted ddf75be47ca748f8b12d28ac64d624354fddf189 now, it still triggers a lockdep splat

20:38 <ukleinek> broonie: I'm convince that the goal of ddf75be47ca748f8b12d28ac64d624354fddf189 should better be reached using the refcounting provided by the device core instead.

20:38 <ukleinek> s/convince/convinced/

20:39 <broonie> I would have thought so too TBH.

20:42 <ukleinek> the lockdep splat is about .io_mutex because there is no nesting annotation

20:54 <ukleinek> ah, that is picked up from the footer of Marek's reply, lol

20:57 <ukleinek> marex: Oh, the joy of corporate email footers: https://git.kernel.org/linus/ce91c6220947e4efa0db564cc50baa0151d8872b

21:02 <ukleinek> geertu: I just learned you used to work for Sony from 746ce939a2729fc6f15944f65d7b15574a243692

21:09 <broonie> ahahah I bet that's b4...

21:09 <broonie> Or could be someone downloading the patch from patchwork as well.

21:10 <marex> ukleinek: much better than plain email ;-)

21:10 <ukleinek> broonie: yeah, happens with b4 on 20210718211143.143557-1-marex@denx.de, too.

21:11 <marex> ukleinek: I actively remove the footer from any ML stuff, maybe I forgot it somewhere accidentally ?

21:12 <ukleinek> marex: b4 picks it up from https://lore.kernel.org/linux-spi/17bf62a4-af57-1706-f20a-35f9d6cbf9d0@denx.de/

21:13 <marex> darn

21:15 <marex> maybe everything under -- should be dropped ?

21:15 <marex> broonie: thanks

21:15 <broonie> b4 probably ought to be --- - yes eactly.

21:15 <marex> well I should also drop those footers from ML traffic, this one got through by accident

21:16 <ukleinek> broonie: I'm about to write a mail to tools@linux.kernel.org

21:16 <broonie> ukleinek: ack

21:18 <marex> btw is b4 collecting the AB tags too ?

21:18 <ukleinek> marex: yes it doesn

21:18 <ukleinek> s/n/./

21:19 <marex> oh

21:21 <ukleinek> marex: it even searches aggressively, e.g. double checks all relevant archives for cross posted patches

21:23 <marex> ukleinek: if I wasn't so tired, I'd probably ask if it picked any ptx footers too :)

21:26 <ukleinek> I think the ptx standard footer doesn't hit that problem in b4. It doesn't match ^[A-Za-z-]*:.*@ which I would expect b4 to use

21:29 <marex> ukleinek: that is not the regex for valid email address though :-)

21:35 <ukleinek> marex: the regex is: ^(\w\S+):\s+.*\S+@\S+\.\S+, which is only little better.

21:36 <marex> ukleinek: I seem to recall it was much longer than that

21:36 <ukleinek> marex: there is no regex to match all valid email addresses

21:38 <marex> ukleinek: how come ?

21:39 <broonie> the regex language is too weak to cope with the full glory of what is permitted by the RFCs.

21:40 <marex> I thought the matching was turing complete, so it should be possible to implement that match

21:40 <marex> but I also saw a rather long attempts, indeed

21:40 <ukleinek> https://www.regular-expressions.info/email.html

22:13 <Pali> ukleinek: I think that regex presented at that site is incomplete

22:14 <Pali> it is missing parsing of nested comments, which are allowed in email addresses per RFC5322 (and lot of people forget about it)

22:15 <Pali> ukleinek: this is "more complete" regex: https://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html

22:17 <marex> that is more what I had in mind, but is that really complete ?

22:17 <Pali> no, due to nested comments

22:17 <Pali> complete regex can be written in Perl regex dialect

22:17 <Pali> it is part of Perl test suite

22:17 <Pali> https://github.com/Perl/perl5/blob/blead/t/re/reg_email.t

22:18 <Pali> line 15

22:19 <Pali> this is fully complete but uses backreferences and other perlre constructions

22:19 <Pali> which basically allows to write grammar-in-regex

22:20 <Pali> and beware that time complexity in the worst case is exponential

22:20 <Pali> (of length of input string to check)

22:25 <Pali> and personal experience? never try to parse or check email address by regex... either it will be incorrect or it can be misused for DoS attacks