search for: accect

...Please let me > know if there's if there's a preferred style for cases like this one. Readability has IMO higher priority than some limit of 80 chars. And it hurts readability (at least my OCD) when style changes as you do with indent here. So my personal preference is to fix indent and accect longer lines. But you ask for a preferred style - which I do not think we have in this case. So it boils down to what you prefer. Enough bikeshedding, thanks for the quick response. Sam

...Please let me > know if there's if there's a preferred style for cases like this one. Readability has IMO higher priority than some limit of 80 chars. And it hurts readability (at least my OCD) when style changes as you do with indent here. So my personal preference is to fix indent and accect longer lines. But you ask for a preferred style - which I do not think we have in this case. So it boils down to what you prefer. Enough bikeshedding, thanks for the quick response. Sam

...9;s if there's a preferred style for cases like this one. >> Readability has IMO higher priority than some limit of 80 chars. >> And it hurts readability (at least my OCD) when style changes >> as you do with indent here. So my personal preference is to fix >> indent and accect longer lines. > > In this case the an often used convention (which is also kind of > readable) is to add a newline after the return values, but before the > function name. E.g. something like this: > > static inline struct drm_gem_vram_object* > drm_gem_vram_of_bo(struct tt...

...9;s if there's a preferred style for cases like this one. >> Readability has IMO higher priority than some limit of 80 chars. >> And it hurts readability (at least my OCD) when style changes >> as you do with indent here. So my personal preference is to fix >> indent and accect longer lines. > > In this case the an often used convention (which is also kind of > readable) is to add a newline after the return values, but before the > function name. E.g. something like this: > > static inline struct drm_gem_vram_object* > drm_gem_vram_of_bo(struct tt...

...tyle for cases like this one. >>>> Readability has IMO higher priority than some limit of 80 chars. >>>> And it hurts readability (at least my OCD) when style changes >>>> as you do with indent here. So my personal preference is to fix >>>> indent and accect longer lines. >>> In this case the an often used convention (which is also kind of >>> readable) is to add a newline after the return values, but before the >>> function name. E.g. something like this: >>> >>> static inline struct drm_gem_vram_object* &g...

...tyle for cases like this one. >>>> Readability has IMO higher priority than some limit of 80 chars. >>>> And it hurts readability (at least my OCD) when style changes >>>> as you do with indent here. So my personal preference is to fix >>>> indent and accect longer lines. >>> In this case the an often used convention (which is also kind of >>> readable) is to add a newline after the return values, but before the >>> function name. E.g. something like this: >>> >>> static inline struct drm_gem_vram_object* &g...

...know if there's if there's a preferred style for cases like this one. > Readability has IMO higher priority than some limit of 80 chars. > And it hurts readability (at least my OCD) when style changes > as you do with indent here. So my personal preference is to fix > indent and accect longer lines. In this case the an often used convention (which is also kind of readable) is to add a newline after the return values, but before the function name. E.g. something like this: static inline struct drm_gem_vram_object* drm_gem_vram_of_bo(struct ttm_buffer_object *bo) Regards, Chri...

...preferred style for cases like this one. > >> Readability has IMO higher priority than some limit of 80 chars. > >> And it hurts readability (at least my OCD) when style changes > >> as you do with indent here. So my personal preference is to fix > >> indent and accect longer lines. > > > > In this case the an often used convention (which is also kind of > > readable) is to add a newline after the return values, but before the > > function name. E.g. something like this: > > > > static inline struct drm_gem_vram_object* > &g...

...ike this one. >>>>> Readability has IMO higher priority than some limit of 80 chars. >>>>> And it hurts readability (at least my OCD) when style changes >>>>> as you do with indent here. So my personal preference is to fix >>>>> indent and accect longer lines. >>>> In this case the an often used convention (which is also kind of >>>> readable) is to add a newline after the return values, but before the >>>> function name. E.g. something like this: >>>> >>>> static inline struct drm...

Hi Thomas. Some minor things and some bikeshedding too. One general^Wbikeshedding thing - unint32_t is used in many places. And then s64 in one place. Seems like two concepts are mixed. Maybe be consistent and use u32, s32 everywhere? I did not read the code carefully enough to understand it. I cannot give a r-b or a-b - as I feel I need to understand it to do so. Sam On Mon, Apr 29, 2019 at

Hi Thomas. Some minor things and some bikeshedding too. One general^Wbikeshedding thing - unint32_t is used in many places. And then s64 in one place. Seems like two concepts are mixed. Maybe be consistent and use u32, s32 everywhere? I did not read the code carefully enough to understand it. I cannot give a r-b or a-b - as I feel I need to understand it to do so. Sam On Mon, Apr 29, 2019 at