<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/usb/eth, branch v2021.01</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/drivers/usb/eth?h=v2021.01</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/drivers/usb/eth?h=v2021.01'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2020-12-16T09:27:09Z</updated>
<entry>
<title>eth/r8152: fix the aggregation issue</title>
<updated>2020-12-16T09:27:09Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-12-16T09:03:23Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=72294407726e9652f4ab44add3dbd118797683d1'/>
<id>urn:sha1:72294407726e9652f4ab44add3dbd118797683d1</id>
<content type='text'>
Remove the redundant setting for USB_RX_EARLY_SIZE. Besides, for
RTL8153B, it is necessary to notify the hardware of the changes
of the aggregation settings.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
<entry>
<title>eth/r8152: free previous memory if r8152_eth_probe fail</title>
<updated>2020-12-16T09:27:09Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-12-16T09:03:22Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=17d5a461a0da967c511032a160278b0e1d9fd349'/>
<id>urn:sha1:17d5a461a0da967c511032a160278b0e1d9fd349</id>
<content type='text'>
The r8152_eth_probe() may allocate a memory for ss-&gt;dev_priv.
It has to be freed if r8152_eth_probe() fails finally.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
<entry>
<title>eth/r8152: support RTL8153B/RTL8154B</title>
<updated>2020-09-01T12:47:36Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-06-16T09:09:47Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3a41086f6afabdeed115f33bedd66eb832dacb86'/>
<id>urn:sha1:3a41086f6afabdeed115f33bedd66eb832dacb86</id>
<content type='text'>
This is used to support RTL8153B and RTL8154B.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
<entry>
<title>eth/r8152: modify rtl_clear_bp function</title>
<updated>2020-09-01T12:47:36Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-06-16T09:09:46Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9f6142aa0a456cda16aa01c3acbf3f22a7c1122f'/>
<id>urn:sha1:9f6142aa0a456cda16aa01c3acbf3f22a7c1122f</id>
<content type='text'>
The original rtl_clear_bp() is used to clear the firmware of both
PLA and USB MCU. The new one could clear the firmware of PLA or
USB independently. It is unnecessary to clear firmware, if there
is no one to be updated.

Besides, clear the firmware by writing the relative registers in
bulk.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
<entry>
<title>eth/r8152: reset PHY after setting it</title>
<updated>2020-09-01T12:47:36Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-06-16T09:09:45Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=16b9417b6ac64e8942064960a7e9b6fc8502a0a3'/>
<id>urn:sha1:16b9417b6ac64e8942064960a7e9b6fc8502a0a3</id>
<content type='text'>
Some settings of PHY have to work after resetting PHY.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
<entry>
<title>eth/r8152: reset bmu after disabling Tx/Rx</title>
<updated>2020-09-01T12:47:36Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-06-16T09:09:44Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d74a76234f1bbbb9c6266ebe55ce53be99a6df19'/>
<id>urn:sha1:d74a76234f1bbbb9c6266ebe55ce53be99a6df19</id>
<content type='text'>
Reset bmu after disabling Tx/Rx. This is used to clear the FIFO of
Tx/Rx. The remained data may be transferred after Tx/Rx is re-enabled.
And it results in garbage data.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
<entry>
<title>treewide: convert bd_t to struct bd_info by coccinelle</title>
<updated>2020-07-17T13:30:13Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2020-06-26T06:13:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b75d8dc5642b71eb029e7cd38031a32029e736cc'/>
<id>urn:sha1:b75d8dc5642b71eb029e7cd38031a32029e736cc</id>
<content type='text'>
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:

  It's a **mistake** to use typedef for structures and pointers.

Besides, using typedef for structures is annoying when you try to make
headers self-contained.

Let's say you have the following function declaration in a header:

  void foo(bd_t *bd);

This is not self-contained since bd_t is not defined.

To tell the compiler what 'bd_t' is, you need to include &lt;asm/u-boot.h&gt;

  #include &lt;asm/u-boot.h&gt;
  void foo(bd_t *bd);

Then, the include direcective pulls in more bloat needlessly.

If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:

  struct bd_info;
  void foo(struct bd_info *bd);

Right, typedef'ing bd_t is a mistake.

I used coccinelle to generate this commit.

The semantic patch that makes this change is as follows:

  &lt;smpl&gt;
  @@
  typedef bd_t;
  @@
  -bd_t
  +struct bd_info
  &lt;/smpl&gt;

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>eth/r8152: update the firmware</title>
<updated>2020-06-14T11:36:29Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-06-05T07:23:40Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=65f7551b6e8e389ae6a6b43ccfd18da31258a9ba'/>
<id>urn:sha1:65f7551b6e8e389ae6a6b43ccfd18da31258a9ba</id>
<content type='text'>
Update the firmware to improve compatibility for none-intel USB
host controller. The more information is as following.

The device has auto-installed driver feature - via switch CD-ROM/NIC
mode. But in some corner cases, it would switch to CD-ROM unexpected.
This issue results in Lan Function Disabled.

While USB PHY transits to P3 from P0 due to the absent of transmitter
control, it would issues undefined signal to its link partner.
Some Down Stream Port misidentify the undefined signal as wakeup
signal. So the link state will not keep in suspend even the system
is idle.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
<entry>
<title>eth/r8152: fix assigning the wrong endpoint</title>
<updated>2020-05-29T17:18:55Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-05-22T08:54:10Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3da0291ba9b4a429ed9226569c9014f5c7e13ac3'/>
<id>urn:sha1:3da0291ba9b4a429ed9226569c9014f5c7e13ac3</id>
<content type='text'>
Although I think it never occurs, the code doesn't make sense, because
it may allow to assign an IN endpoint to ss-&gt;ep_out.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
<entry>
<title>eth/r8152: fix typo in register name</title>
<updated>2020-05-22T13:22:37Z</updated>
<author>
<name>Hayes Wang</name>
<email>hayeswang@realtek.com</email>
</author>
<published>2020-05-22T08:54:11Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2cff87f7abf060dda00302680f051d5e9ce60ab9'/>
<id>urn:sha1:2cff87f7abf060dda00302680f051d5e9ce60ab9</id>
<content type='text'>
The PAL_BDC_CR should be PLA_BDC_CR.

Signed-off-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
</content>
</entry>
</feed>
