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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+jGjxYDo2+cpmLWNB4HFTBS_iDR3PMk_vm5xSH_S6qmw@mail.gmail.com>
Date:	Tue, 9 Aug 2016 13:39:31 -0500
From:	Rob Herring <robh+dt@...nel.org>
To:	Timur Tabi <timur@...eaurora.org>
Cc:	Lino Sanfilippo <LinoSanfilippo@....de>,
	netdev <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	Sagar Dharia <sdharia@...eaurora.org>,
	Shanker Donthineni <shankerd@...eaurora.org>,
	Vikram Sethi <vikrams@...eaurora.org>,
	Christopher Covington <cov@...eaurora.org>,
	Gilad Avidov <gavidov@...eaurora.org>,
	Andrew Lunn <andrew@...n.ch>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Mark Langsdorf <mlangsdo@...hat.com>,
	"jcm@...hat.com" <jcm@...hat.com>,
	Andy Gross <agross@...eaurora.org>,
	David Miller <davem@...emloft.net>,
	Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

On Tue, Aug 9, 2016 at 1:25 PM, Timur Tabi <timur@...eaurora.org> wrote:
> Lino Sanfilippo wrote:
>
>>> +/* 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