Re: [PATCH v2 00/12] i2c-pxa cleanups

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

On Mon, Apr 27, 2020 at 07:46:58PM +0100, Russell King - ARM Linux admin wrote:
> Hi,
> 
> This series cleans up the i2c-pxa code via the following changes:
> 
> 1. replace i2c_pxa_addr_byte() with the functional equivalent
>    i2c_8bit_addr_from_msg().
> 
> 2. removing unnecessary headers, and rearranging those that remain
>    in alphabetical order.
> 
> 3. rearranging functions in the file to flow better; particularly
>    placing the PIO specific functions next to the PIO algorithm
>    structure, so all the PIO mode related code is together.  This
>    eliminates the forward declaration of i2c_pxa_handler().
> 
> 4. group the register bitfield definitions, which were split over two
>    separate locations in the file, into a single location, and add
>    some definitions for the IBMR register.
> 
> 5. always set the 'fm' and 'hs' members for each hardware type; the
>    storage for these members is always allocated, we don't need to
>    bloat the code (neither runtime, nor in the source) for this.
> 
> 6. move definitions private to i2c-pxa out of the platform data
>    header; platforms have no business knowing these details.
> 
> 7. group all driver-based IDs match (platform and OF) to one common
>    location rather than at either end of the file.
> 
> 8. fix i2c_pxa_scream_blue_murder()'s log output to be printed on a
>    single line as it was intended, rather than being printed one
>    entry per line - which makes it difficult to read particularly
>    when it has been enabled and you're getting lots of them.  Also
>    fix decode_bits() output in the same way.
> 
> 9. fix i2c_pxa_wait_bus_not_busy() boundary condition, so that a
>    coincidental success and timeout results in the function being
>    successful rather than failing. (This has never been seen in
>    practice, but was spotted while reviewing the code.)
> 
> All in all, these changes should have (and have had so far) no
> observable impact on the driver; therefore, I do not see any reason
> to backport any of these changes to stable trees.
> 
> This series has been rebased on the linux-i2c for-next branch.

Applied all to for-next, thanks!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]