06:51 <krzk> marc|gonzalez: if invoked as cc-cmd then yes, so I've been posting this for long enough already: https://github.com/krzk/tools/blob/master/linux/.bash_aliases_linux#L91

06:52 <krzk> but as everyone is saying since some time, me included, switch to b4 instead...

07:02 <krzk> marc|gonzalez: and just in case: since you decide not even to use get_maintainers in cc-cmd (thus do not send to maintainers) I, and probably Conor as well, am going to ignore your patches

07:02 <krzk> you might still get ack from Rob, most likely

07:03 <krzk> but then don't be surprised or do not complain it takes time... it's your cc-list

07:40 <krzk> abhinav__: that's some bikeschedding, even too much, but to answer your concerns - the bus between DSI and panel is not unidirectional, because you have BTA on first data link, so some data can go from panel to DSI (or maybe even does go). So if this one graph connection represents bi-directional bus, what is wrong in adding GPIO/interrupt property there? It fits the bi-directional approach and fits the

07:40 <krzk> graph concept (see graph bindings).

17:21 <abhinav__> krzk but today we do not have any property or a pin for BTA because its only a signal on lane0, but the TE is a physical pin. thats the difference

17:21 <abhinav__> so its not just bikeschedding, but to get things right

17:34 <abhinav__> because the label dsi0_out under which we are placing the property looks confusing or poorly named then

20:30 <z3ntu> Yes, it's in my inbox, thanks for giving me a poke :)