Thread (1 message) 1 message, 1 author, 2016-08-09

Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

From: Rob Herring <hidden>
Date: 2016-08-09 18:39:31
Also in: linux-arm-msm, linux-devicetree

On Tue, Aug 9, 2016 at 1:25 PM, Timur Tabi [off-list ref] wrote:
Lino Sanfilippo wrote:
quoted
quoted
+/* Fill up transmit descriptors */
+static void emac_tx_fill_tpd(struct emac_adapter *adpt,
+                            struct emac_tx_queue *tx_q, struct sk_buff
*skb,
+                            struct emac_tpd *tpd)
+{
+       u16 nr_frags = skb_shinfo(skb)->nr_frags;
+       unsigned int len = skb_headlen(skb);
+       struct emac_buffer *tpbuf = NULL;
+       unsigned int mapped_len = 0;
+       unsigned int i;
+       int ret;
+
+       /* if Large Segment Offload is (in TCP Segmentation Offload
struct) */
+       if (TPD_LSO(tpd)) {
+               mapped_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
+
+               tpbuf = GET_TPD_BUFFER(tx_q, tx_q->tpd.produce_idx);
+               tpbuf->length = mapped_len;
+               tpbuf->dma_addr =
dma_map_single(adpt->netdev->dev.parent,
+                                                skb->data, mapped_len,
+                                                DMA_TO_DEVICE);
+               ret = dma_mapping_error(adpt->netdev->dev.parent,
+                                       tpbuf->dma_addr);
+               if (ret) {
+                       dev_kfree_skb(skb);
+                       return;
+               }
+
+               TPD_BUFFER_ADDR_L_SET(tpd,
lower_32_bits(tpbuf->dma_addr));
+               TPD_BUFFER_ADDR_H_SET(tpd,
upper_32_bits(tpbuf->dma_addr));

You should also take big endian systems into account. This means that if
the multi-byte values
in the descriptors require little-endian you have to convert from host
byte order to le and
vice versa. You can use cpu_to_le32() and friends for this.

I used to work on PowerPC, so I respect making things work for both endians.
However, even I think that this is overkill for my driver. First, there's no
way this driver will ever be used on a big-endian system.  Second, I'm
pretty sure there are lots of places that would need cpu_to_le32() in order
to make this driver big-endian compatible. It would be a huge mess.
I thought that too about Calxeda systems and then someone went off and
made them run BE. I was surprised it worked, but I guess when the h/w
doesn't try to do swizzling of i/o things just work.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help