1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
09:28 < geertu> Welcome to today's Core Group Chat Meeting!
09:28 < geertu> Agenda:
09:28 < geertu> 1. Status Updates
09:28 < geertu> 2. Discussion Topics
09:28 < geertu> Topic 1. Status updates
09:28 < geertu> A) What have we done since last time:
09:28 < geertu> Marek converted the U-Boot PCNET and EEPRO100 drivers to DM, added CI
09:28 < geertu> tests for them, and synced the U-Boot Gen2 MSTP tables.
09:28 < geertu> Morimoto-san worked on Renesas inside Paper Work, and updated his local
09:28 < geertu> machine.
09:28 < geertu> Shimoda-san submitted DT binding doc conversions ({rcar,usb}-dmac,
09:28 < geertu> ipmmu) and fixes for IOMMU device node names.
09:28 < geertu> Geert did more DT binding doc conversions (bsc, em,gio, rza1-irqc, cpg),
09:28 < geertu> leading to more DTS and dt-schema fixes, reviewed lots of RZ/G1H
09:28 < geertu> patches, and started looking into implementing QEMU gpiodev support as
09:28 < geertu> an interface.
09:29 < geertu> B) What we plan to do till next time:
09:29 < geertu> Marek plans to convert the U-Boot dc2114x driver to DM and add CI tests
09:29 < geertu> for it, and prepare for the 2020.07 release.
09:29 < geertu> Shimoda-san plans to convert the iommu doc to json-schema, and add
09:29 < geertu> r8a77961 support.
09:29 < geertu> Geert plans to refactor the GPIO Aggregator parsing, do more DT binding
09:29 < geertu> doc conversions, and will continue QEMU GPIO virtualization.
09:29 < geertu> C) Problems we have currently:
09:29 < geertu> Geert is struggling with describing multi-level sh-pfc subnodes in
09:29 < geertu> json-schema.
09:30 < geertu> ---EOL---
09:30 < geertu> Anything I missed?
09:31 < geertu> Topic 2. Discussion Topics
09:31 < geertu> Please shoot your topics
09:32 < kbingham> pm_runtime_put_idle()
09:32 * kbingham ducks.
09:32 < geertu> kbingham: I'm waiting for Rafael to chime in ;-)
09:32 < kbingham> that topic is horrrrrrible.
09:33 < wsa> what's the context?
09:33 < kbingham> They're basically saying "Sure - thaat would be the right way to do it ... but I don't want to fix everything"
09:33 < wsa> I know it from SDHI :/
09:34 < geertu> wsa: The question is: what is the right pm_runtime_*() call to make when pm_runtime_get_sync() failed
09:34 < Marex> kbingham: did I miss something ? there was a patch for PCI too
09:34 < geertu> I've seen pm_runtime_put(), pm_runtime_put_idle(), pm_runtime_idle(), pm_runtime_put_noidle(), ...
09:35 < kbingham> when pm_runtime_get_sync() fails, it doesn't leave the system in the same state as when the function was entered. i.e. it takes a refcount unconiditionally.
09:35 < kbingham> how to clean up if it fails is a ... seemingly horrible mess.
09:35 < wsa> and why does it increment the refcnt?
09:35 < kbingham> And no one wants to fix the function to clean itself up - becasue tehre are also lots of code paths which rely on the get_sync() incrementing, because they later decrement.
09:36 < kbingham> Which is ... stupid ...
09:36 < kbingham> because if the get_sync() fails, then surely you cant rely on the code between the get and the put to work anyway!
09:37 < wsa> yes, without knowing details, it seems right to me to fix the function itself
09:37 < wsa> even if it is a lot of work
09:37 < kbingham> I'm scared to reply to the thread fearing what I'd get dragged into - but I'm surprised that no one else has said "Ugh ... that's wrong?"
09:38 < wsa> maybe everone is scared?
09:38 < wsa> i have patches for this in my I2C inbox but I was really wondering about them
09:38 < wsa> it just feels wrong
09:38 < geertu> wsa: http://lore.kernel.org/r/5127441.yGvM1JjtLk@kreacher
09:38 < wsa> but I wanted to tackle it after I completed the merge window
09:39 < kbingham> I'm going to have to add linux-pm to my lists aren't I :S
09:39 < kbingham> at least it's easy to pull in with nntp support on lore.
09:40 < geertu> pinchartl: So you think we should always handle pm_runtime_get_sync() failures?
09:40 < shimoda> oops, about pm_runtime_get_sync(), i also got such a patch for rcar-pci, and i had submitted my R-b... Should I recall?
09:40 * geertu admits not having looked in all its failure modes
09:41 < kbingham> shimoda, techincally the patch is probably 'right' currently ... it's just the wrong way to do the real fixes.
09:41 < geertu> shimoda: The bad thing is that these patches are sent out by copycats who don't know what they're changing.
09:41 < kbingham> yup... looks like a big batch conversion finding matches with cocci
09:41 < kbingham> which implies that the 'lot of work to fix the other paths' is ... just the same route - and thus entirely feasible ;-)
09:42 < wsa> well, we could use coccinelle the same way to convert most of the drivers relying on the refcnt being increased
09:42 < kbingham> precisely ;-)
09:42 < wsa> I wonder if there is a reason why incrementing the refcnt makes sense
09:43 < wsa> I will start another thread right away and ask Rafael; I will CC renesas-soc
09:43 < kbingham> oops hit the wrong option, and now downloading 136475 headers from linux-pm :-(
09:43 < wsa> yay, another item for my B) list
09:44 < kbingham> Ok - so I think that finalises my discussion point ...
09:44 < kbingham> Anything else?
09:46 < wsa> next meeting?
09:47 < geertu> Thursday, July 9?
09:47 < wsa> I am very likely on holiday then, and the week after
09:48 < wsa> July, 2nd?
09:49 < shimoda> July, 2nd is OK to me
09:49 < geertu> That's during ELC-NA ;-)
09:49 < wsa> i see
09:49 < geertu> However, I can handle
09:50 < geertu> As everything is virtual these days
09:50 < morimoto> geertu: Do you join ELC-NA ?
09:50 < geertu> morimoto: Yes I will
09:50 < morimoto> Is it by-F2F or by-net ?
09:50 < geertu> Pay 750 USD less, and avoid ESTA/TSA, so why not? ;-)
09:50 < geertu> morimoto: by-net, 50 USD only
09:51 < pinchartl> geertu: I'm not sure we shoudl always handle them
09:51 < morimoto> OK, nice to know :)
09:51 < pinchartl> it was a real question, I don't know if there could be valid cases where the call fails
09:51 < Marex> morimoto: you can always hang around this irc and socialize with everyone , for $0
09:51 < wsa> I won't have internet during my holidays, so I'd like some wrap-up before I leave
09:52 < morimoto> Marex: hehe $0 is nice :)
09:52 < morimoto> Marex: without T-shot :(
09:53 < wsa> so, if it does not collide too much with ELC, I'd like the July, 2nd
09:53 < morimoto> s/T-shot/T-shirt
09:53 < geertu> wsa: Are you allowed to move to no-Internet zones with covid-19 still around?
09:54 < morimoto> July 2nd is OK for me, too
09:54 * geertu thought t-shot was right, in a comment for Marex ;-)
09:56 < wsa> geertu: we go canoeing, so we won't see much people (hopefully!) :)
09:57 < geertu> Any other topics?
09:58 < geertu> July 2nd it will be?
09:59 < Marex> sounds good
09:59 < geertu> Thanks for joining, and have a nice continued day!
|
