linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Chris Snook <chris.snook@gmail.com>
Cc: Zhang Changzhong <zhangchangzhong@huawei.com>,
	Jay Cliburn <jcliburn@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	yanaijie@huawei.com, christophe.jaillet@wanadoo.fr,
	mst@redhat.com, Leon Romanovsky <leon@kernel.org>,
	jesse.brandeburg@intel.com, netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net] atl1c: fix error return code in atl1c_probe()
Date: Tue, 17 Nov 2020 10:01:32 +0100	[thread overview]
Message-ID: <7fae4733-570c-6cb1-5537-de6469afbea5@gmail.com> (raw)
In-Reply-To: <CAMXMK6v+nAdcChQ4wkc8gRt6i1uwGHgnmqBvZf9k-HFmPkSWcQ@mail.gmail.com>

Am 17.11.2020 um 08:43 schrieb Chris Snook:
> The full text of the preceding comment explains the need:
> 
> /*
> * The atl1c chip can DMA to 64-bit addresses, but it uses a single
> * shared register for the high 32 bits, so only a single, aligned,
> * 4 GB physical address range can be used at a time.
> *
> * Supporting 64-bit DMA on this hardware is more trouble than it's
> * worth.  It is far easier to limit to 32-bit DMA than update
> * various kernel subsystems to support the mechanics required by a
> * fixed-high-32-bit system.
> */
> 
> Without this, we get data corruption and crashes on machines with 4 GB
> of RAM or more.
> 
> - Chris
> 
> On Mon, Nov 16, 2020 at 11:14 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>
>> Am 17.11.2020 um 03:55 schrieb Zhang Changzhong:
>>> Fix to return a negative error code from the error handling
>>> case instead of 0, as done elsewhere in this function.
>>>
>>> Fixes: 85eb5bc33717 ("net: atheros: switch from 'pci_' to 'dma_' API")
>>> Reported-by: Hulk Robot <hulkci@huawei.com>
>>> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
>>> ---
>>>  drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
>>> index 0c12cf7..3f65f2b 100644
>>> --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
>>> +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
>>> @@ -2543,8 +2543,8 @@ static int atl1c_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>        * various kernel subsystems to support the mechanics required by a
>>>        * fixed-high-32-bit system.
>>>        */
>>> -     if ((dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)) != 0) ||
>>> -         (dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)) != 0)) {
>>> +     err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
>>
>> I wonder whether you need this call at all, because 32bit is the default.
>> See following
>>
>> "By default, the kernel assumes that your device can address 32-bits
>> of DMA addressing."
>>
>> in https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt
>>
>>> +     if (err) {
>>>               dev_err(&pdev->dev, "No usable DMA configuration,aborting\n");
>>>               goto err_dma;
>>>       }
>>>
>>

Please don't top-post.
>From what I've seen the kernel configures 32bit as default DMA size.
See beginning of pci_device_add(), there the coherent mask is set to 32bit.

And in pci_setup_device() see the following:
  /*
         * Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer)
         * set this higher, assuming the system even supports it.
         */
        dev->dma_mask = 0xffffffff;


That means if you would like to use 64bit DMA then you'd need to configure this explicitly.
You could check to which mask dev->dma_mask and dev->coherent_dma_mask are set
w/o the call to dma_set_mask_and_coherent.


  reply	other threads:[~2020-11-17  9:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17  2:55 [PATCH net] atl1c: fix error return code in atl1c_probe() Zhang Changzhong
2020-11-17  7:14 ` Heiner Kallweit
2020-11-17  7:43   ` Chris Snook
2020-11-17  9:01     ` Heiner Kallweit [this message]
2020-11-17  9:21       ` Chris Snook
2020-11-17 20:39 ` Marion & Christophe JAILLET
2020-11-17 20:45   ` Jakub Kicinski
2020-11-18 19:10 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7fae4733-570c-6cb1-5537-de6469afbea5@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=chris.snook@gmail.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=davem@davemloft.net \
    --cc=jcliburn@gmail.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=yanaijie@huawei.com \
    --cc=zhangchangzhong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).