hello,
below is a diff to fix a regression on re chips which have
7k jumbo support (RL_JUMBO_MTU_7K) as reported by daniel jakots
and emilio perea. the regression was caused because RL_JUMBO_FRAMELEN
was changed to 9k and i missed fixing up the RL_JUMBO_MTU_7K macro.
Index: rtl81x9reg.h
On Wed, Feb 18, 2015 at 11:23:15AM +1000, David Gwynne wrote:
it looks like it reads the DCSR register and then keeps everything
except the MPS field.
this might cause it to erronously consider the mps to be much bigger
than 2048, which in turn could prevent it from setting it correctly.
On Fri, Jan 23, 2015 at 11:26:53AM +1000, David Gwynne wrote:
a compromise could be to advertise checksum offload to the stack,
pass it on to the hardware for small frames but have the driver do
it in software for the big ones?
greetings,
below are two diffs. the first allows re(4) chips to
On Thu, Jan 22, 2015 at 08:52:25PM +, Stuart Henderson wrote:
some minor things I spotted:
slight KNF issues, some of the new lines are 80 columns.
+ case RL_HWREV_8168E:
+ CSR_WRITE_1(sc, RL_CFG4, CSR_READ_1(sc, RL_CFG4) | 0x01);
+ break;
+ default:
hi all,
the below diff enables support for jumbo frames on
some newer re(4) devices. i've tested it on 8186D/8111D
and 8186E/8111E chips, which are both able to do 9k
jumbos. it seems to provide a significant speed-up on
simple file transfer tests. most of the important parts
were taken from the
On 2 Jan 2015, at 4:15 pm, David Gwynne da...@gwynne.id.au wrote:
can someone test this?
it allocates storage for the volume change details rather than cast
arguments to a single global task.
adds some safety while there if audio0 is a hotplug device.
ok?
The keyboard audio controls
