{"push_id":673988659,"size":1,"distinct_size":1,"ref":"refs/heads/gpio-ops","head":"3db284b4076c39b32431be4681f5eff13decf02f","before":"3ee12d105a14e8da0bf3d5c83a842cb16a9fb6f2","commits":[{"sha":"3db284b4076c39b32431be4681f5eff13decf02f","author":{"email":"039000e09e601bba70626bd0fbe59654c9cf8cac@collabora.co.uk","name":"Javier Martinez Canillas"},"message":"gpio: add struct gpio_chip_ops to abstract GPIO controller operations\n\nIn the kernel there are basically two patterns to implement object\noriented code in C. You can either embed a set of function pointers\nin a struct along with other members or have a separate virtual function\ntable (vtable) structure that hold all the functions and only store a\npointer to that vtable on our particular object.\n\nThe struct gpio_chip uses the former approach, but I don't know if that\nis a design decision or is just that this code predates the fact that\nthe separate structure pattern is now so popular. Since having the\noperations on a different structure has a number of benefits:\n\n- A clean separation between state (fields) and operations (functions).\n- Requires a single assignment instead of many in the driver's init function.\n- Size reduction of struct gpio_chip since will only hold one pointer.\n- These functions are not supposed to change at runtime so the const\n  qualifier can be used to prevent pointers modification during execution.\n- Similar drivers for a chip family can reuse their function vtable.\n\nThere is a drawback though which is that now two memory accesses are\nneeded to execute a GPIO operation since an additional level of\nindirection is introduced but that should be minimized due temporal and\nspatial memory locality.\n\nThis patch adds a struct gpio_chip_ops to be set by GPIO chip controllers.\n\nSigned-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>","distinct":true,"url":"https://api.github.com/repos/martinezjavier/linux/commits/3db284b4076c39b32431be4681f5eff13decf02f"}]}