[GIT,PULL] arch/microblaze patches for 6.2-rc1

Message ID b7ece19c-e50e-0709-7be1-2945883d155b@monstr.eu
State New
Headers
Series [GIT,PULL] arch/microblaze patches for 6.2-rc1 |

Pull-request

git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-v6.2

Message

Michal Simek Dec. 8, 2022, 10:07 a.m. UTC
  Hi Linus,

please pull these changes to your tree. They are cleaning up the PCI bus support 
which was pretty much c&p from PowerPC long time ago for one custom platform 
which is not available for years. Finally Xilinx/AMD PCIe team tested Microblaze 
with IP cores also used on ARM SOCs and clean up Microblaze code.

Thanks,
Michal


The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:

   Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)

are available in the Git repository at:

   git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-v6.2

for you to fetch changes up to 5cfe469c2654c3a4dda8504b1209abdd8b379e95:

   microblaze/PCI: Moving PCI iounmap and dependent code (2022-11-25 11:39:23 +0100)

----------------------------------------------------------------
Microblaze patches for 6.2-rc1

- Cleanup PCI support

----------------------------------------------------------------
Thippeswamy Havalige (13):
       microblaze/PCI: Remove unused early_read_config_byte() et al declarations
       microblaze/PCI: Remove Null PCI config access unused functions
       microblaze/PCI: Remove unused PCI bus scan if configured as a host
       microblaze/PCI: Remove unused PCI legacy IO's access on a bus
       microblaze/PCI: Remove unused device tree parsing for a host bridge resources
       microblaze/PCI: Remove unused allocation & free of PCI host bridge structure
       microblaze/PCI: Remove unused PCI BIOS resource allocation
       microblaze/PCI: Remove unused PCI Indirect ops
       microblaze/PCI: Remove unused pci_address_to_pio() conversion of CPU 
address to I/O port
       microblaze/PCI: Remove unused sys_pciconfig_iobase() and et al declaration
       microblaze/PCI: Remove unused pci_iobar_pfn() and et al declarations
       microblaze/PCI: Remove support for Xilinx PCI host bridge
       microblaze/PCI: Moving PCI iounmap and dependent code

  arch/microblaze/Kconfig                  |    8 -
  arch/microblaze/configs/mmu_defconfig    |    1 -
  arch/microblaze/include/asm/pci-bridge.h |   92 --
  arch/microblaze/include/asm/pci.h        |   29 -
  arch/microblaze/pci/Makefile             |    3 +-
  arch/microblaze/pci/indirect_pci.c       |  158 ---
  arch/microblaze/pci/iomap.c              |   36 +
  arch/microblaze/pci/pci-common.c         | 1067 --------------------
  arch/microblaze/pci/xilinx_pci.c         |  170 ----
  9 files changed, 37 insertions(+), 1527 deletions(-)
  delete mode 100644 arch/microblaze/pci/indirect_pci.c
  delete mode 100644 arch/microblaze/pci/pci-common.c
  delete mode 100644 arch/microblaze/pci/xilinx_pci.c
  

Comments

Linus Torvalds Dec. 12, 2022, 5:49 p.m. UTC | #1
On Thu, Dec 8, 2022 at 2:07 AM Michal Simek <monstr@monstr.eu> wrote:
>
> Microblaze patches for 6.2-rc1
>
> - Cleanup PCI support

That tag looks normal in the email, but it's actually nastily encoded.
When I fetched it, I did this:

     git cat-file tag FETCH_HEAD | hexdump -c

and it shows

...
0000080   9   3   5   4   6       +   0   1   0   0  \n  \n   M   i   c
0000090   r   o   b   l   a   z   e 302 240   p   a   t   c   h   e   s
00000a0 302 240   f   o   r 302 240   6   .   2   -   r   c   1  \n  \n
00000b0   -       C   l   e   a   n   u   p       P   C   I       s   u
00000c0   p   p   o   r   t  \n   -   -   -   -   -   B   E   G   I   N
...

Note how the "spaces" between "Microblaze", "patches", "for" and "6.2"
are not actually regular space characters, but \xc2\a0, which is utf-8
encoding for unicode character A0 ("no-break space").

Please don't do that.  I have my editor show odd characters as hex
codes (I don't want any hidden information), which is why I noticed,
and I'm not sure why/how you did it.

               Linus
  
pr-tracker-bot@kernel.org Dec. 12, 2022, 6:07 p.m. UTC | #2
The pull request you sent on Thu, 8 Dec 2022 11:07:27 +0100:

> git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-v6.2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/164f59000c19fa1ee5d09327a8055ec9f9b9905a

Thank you!
  
Michal Simek Dec. 13, 2022, 7:53 a.m. UTC | #3
On 12/12/22 18:49, Linus Torvalds wrote:
> On Thu, Dec 8, 2022 at 2:07 AM Michal Simek <monstr@monstr.eu> wrote:
>>
>> Microblaze patches for 6.2-rc1
>>
>> - Cleanup PCI support
> 
> That tag looks normal in the email, but it's actually nastily encoded.
> When I fetched it, I did this:
> 
>       git cat-file tag FETCH_HEAD | hexdump -c
> 
> and it shows
> 
> ...
> 0000080   9   3   5   4   6       +   0   1   0   0  \n  \n   M   i   c
> 0000090   r   o   b   l   a   z   e 302 240   p   a   t   c   h   e   s
> 00000a0 302 240   f   o   r 302 240   6   .   2   -   r   c   1  \n  \n
> 00000b0   -       C   l   e   a   n   u   p       P   C   I       s   u
> 00000c0   p   p   o   r   t  \n   -   -   -   -   -   B   E   G   I   N
> ...
> 
> Note how the "spaces" between "Microblaze", "patches", "for" and "6.2"
> are not actually regular space characters, but \xc2\a0, which is utf-8
> encoding for unicode character A0 ("no-break space").
> 
> Please don't do that.  I have my editor show odd characters as hex
> codes (I don't want any hidden information), which is why I noticed,
> and I'm not sure why/how you did it.

It is not done intentionally. I am looking at previous commit messages and I do 
c&p the first line from firefox via gitweb interface. This is style I use for 
years but I see when I do it now that there are added additional chars as you 
mentioned above.

I tracked it down that it started to behave like this between Oct 11/Nov 22 
(from my U-Boot tags) and it is actually firefox (which was upgraded) who is 
adding additional chars there. When I do the same style via chrome I can't see 
any issue.

I will start to write the whole message by hand without c&p to make sure that it 
won't happen again.

Thanks,
Michal