On Wed, Mar 14, 2018 at 12:14:15PM +0000, Robin Murphy wrote: > >>On Wed, Mar 14, 2018 at 8:12 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > >>>On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote: > >>>>On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam <vivek.gautam@xxxxxxxxxxxxxx> wrote: > >>>>>On Tue, Mar 13, 2018 at 3:45 PM, Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > >>>>>>On Tue, Mar 13, 2018 at 5:55 PM, Vivek Gautam <vivek.gautam@xxxxxxxxxxxxxx> wrote: > >>>>>>>The lists managing the device-links can be traversed to > >>>>>>>find the link between two devices. The device_link_add() APIs > >>>>>>>does traverse these lists to check if there's already a link > >>>>>>>setup between the two devices. > >>>>>>>So, add a new APIs, device_link_find(), to find an existing > >>>>>>>device link between two devices - suppliers and consumers. > >>>>>> > >>>>>>I'm wondering if this API would be useful for anything else that the > >>>>>>problem we're trying to solve with deleting links without storing them > >>>>>>anywhere. Perhaps a device_link_del_dev(consumer, supplier) would be a > >>>>>>better alternative? > >>>>> > >>>>>Yea, that sounds simpler i think. Will add this API instead of > >>>>>find_link(). Thanks. > >>>> > >>>>Perhaps let's wait for a moment to see if there are other opinions. :) > >>>> > >>>>Rafael, Lucas, any thoughts? > >>> > >>>It is not clear to me what the device_link_del_dev(consumer, supplier) > >>>would do. > > Not quite - the issue here is that we have one supplier with an arbitrarily > large number of consumers, and would prefer that supplier not to have to > spend a whole bunch of memory to store all the struct device_link pointers > for the sole reason of having something to give to device_link_del() at the > end, given that the device links code is already keeping track of everything > internally anyway. Makes sense to me. How about an additional flag which autoremoves the link on provider unbind? Thanks, Lukas -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
