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] [day] [month] [year] [list]
Date:	Fri, 09 Aug 2013 13:38:21 +0200
From:	khalasa@...p.pl (Krzysztof HaƂasa)
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	linux-kernel@...r.kernel.org,
	James Bottomley <JBottomley@...allels.com>,
	"David S. Miller" <davem@...emloft.net>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: DMA masks

Russell King - ARM Linux <linux@....linux.org.uk> writes:

> No.  If dma_mask is NULL, then dma_set_mask() will return -EIO no matter
> what.  If dma_mask is non-NULL, dma_set_mask() will succeed if the mask
> is supported by the hardware.  For example, on x86:

> and this is the same pattern we implement on ARM.  So, a valid dma_mask
> pointer pointing at a variable holding zero can have a supported mask
> set.

Right. So is it a work around systems unable to provide DMA to devices,
whose drivers would try to use the DMA (not aware of the system
limitations)?

Do you know, by chance, of any particular case using this NULL pointer
trick to prevent (I suppose) a driver from doing DMA?

> Have you looked at my massive dma-masks patch series earlier this week?
> Obviously you haven't...

Right again, no time for basically anything here :-( Will look.

> The separate coherent and streaming masks are only required for a very
> small subset of devices (rather systems - non-ARM I add).  For the
> general case, especially on ARM where the above pattern seems to be
> very prevalent, this does not apply; the two masks are always the same.
> Many people took the above shortcut, and while not strictly correct, it
> is a work-around for the shortcoming in the core device code.

That's my impression, too. BTW I personally have a device (PCI card)
which have different masks (so it's also the case with devices). Old
story though.

> Greg has agreed to having stream_dma_mask in the struct device, but
> even so I think removing the direct initialization from drivers is a good
> idea.

Definitely. I'll take a look, Thanks.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ