On Tue, 2013-12-24 at 12:55 +1100, Anton Blanchard wrote:
The hypervisor expects MAC addresses passed in registers to be big
endian u64. Create a helper function called ibmveth_encode_mac_addr
which does the right thing in both big and little endian.
We were storing the MAC address in a
On 23.12.2013, at 07:38, Anton Blanchard an...@samba.org wrote:
Hi Alex,
The ibmveth driver is memcpy()'ing the mac address between a variable
(register) and memory. This assumes a certain endianness of the
system, so let's make that implicit assumption work again.
Nice catch! I don't
On Mon, 2013-12-23 at 17:38 +1100, Anton Blanchard wrote:
The hypervisor expects MAC addresses passed in registers to be big
endian u64.
So maybe use __be64 declarations?
+static unsigned long ibmveth_encode_mac_addr(char *mac)
static __be64 ibmveth_encode_mac_addr(const char *mac)
?
The hypervisor expects MAC addresses passed in registers to be big
endian u64. Create a helper function called ibmveth_encode_mac_addr
which does the right thing in both big and little endian.
We were storing the MAC address in a long in struct ibmveth_adapter.
It's never used so remove it - we
On Mon, 2013-12-23 at 06:52 -0800, Joe Perches wrote:
On Mon, 2013-12-23 at 17:38 +1100, Anton Blanchard wrote:
The hypervisor expects MAC addresses passed in registers to be big
endian u64.
So maybe use __be64 declarations?
+static unsigned long ibmveth_encode_mac_addr(char *mac)
The ibmveth driver is memcpy()'ing the mac address between a variable
(register) and memory. This assumes a certain endianness of the
system, so let's make that implicit assumption work again.
This patch adds be64_to_cpu() calls to all places where the mac address
gets memcpy()'ed into a local
Hi Alex,
The ibmveth driver is memcpy()'ing the mac address between a variable
(register) and memory. This assumes a certain endianness of the
system, so let's make that implicit assumption work again.
Nice catch! I don't like how the driver has two different methods
for creating these MAC
