[PATCH] pci: print out DMA mask info - Kernel

This is a discussion on [PATCH] pci: print out DMA mask info - Kernel ; On Fri, Oct 10, 2008 at 09:46:33AM -0700, Yinghai Lu wrote: > Matthew Wilcox wrote: > > > > By the way, commit 8f286c33f1e838d631f4a3260b33efce4bc5973c is a really > > bad idea. It is very helpful to see which bitmasks are ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 42

Thread: [PATCH] pci: print out DMA mask info

  1. Re: [PATCH] pci: print out DMA mask info

    On Fri, Oct 10, 2008 at 09:46:33AM -0700, Yinghai Lu wrote:
    > Matthew Wilcox wrote:
    > >
    > > By the way, commit 8f286c33f1e838d631f4a3260b33efce4bc5973c is a really
    > > bad idea. It is very helpful to see which bitmasks are used by real
    > > devices, and which ones aren't. It should be reverted, IMO.

    >
    > why? did you point to wrong commit?


    No, that's the commit I meant.

    > commit 8f286c33f1e838d631f4a3260b33efce4bc5973c
    > Author: Andrew Morton
    > Date: Thu Oct 18 03:05:07 2007 -0700
    >
    > -#define DMA_BIT_MASK(n) ((1ULL<<(n))-1)
    > +#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
    >
    > -#define DMA_64BIT_MASK (~0ULL)
    > +/*
    > + * NOTE: do not use the below macros in new code and do not add new definitions
    > + * here.
    > + *
    > + * Instead, just open-code DMA_BIT_MASK(n) within your driver


    Open-coding DMA_BIT_MASK() within your driver means that we no longer
    have a canonical list of DMA masks in one place. Instead we have to
    grep the entire tree and come up with more-or-less complex scripts to
    figure out which bit masks are actually in use.

    --
    Matthew Wilcox Intel Open Source Technology Centre
    "Bill, look, we understand that you're interested in selling us this
    operating system, but compare it to ours. We can't possibly take such
    a retrograde step."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] pci: print out DMA mask info

    > Open-coding DMA_BIT_MASK() within your driver means that we no longer
    > have a canonical list of DMA masks in one place. Instead we have to
    > grep the entire tree and come up with more-or-less complex scripts to
    > figure out which bit masks are actually in use.


    Out of curiousity, why do we care about that list?

    - R.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] pci: print out DMA mask info

    On Fri, Oct 10, 2008 at 11:40:56AM +0900, FUJITA Tomonori wrote:
    > IIRC, except for one SGI architecture, coherent_dma_mask is
    > meaningless, dma_mask is always equal to coherent_dma_mask.


    Not correct. Several PCI-X devices can only do 32-bit DMA to control
    data but can do 64-bit DMA for payload data. I don't have the list off
    the top of my head but that is the origin of coherent DMA mask.

    > Lots of
    > IOMMU implementations ignore coherent_dma_mask and use dma_mask for
    > alloc_coherent().


    That sounds like a bug. And I don't think it's "lots".

    > Some drivers don't set up coherent_dma_mask.


    They probably should. Current default is 32-bits for PCI devices.

    > Theoretically, we need to fix this but it doesn't cause any
    > problem. That's why nobody cares about it, I guess.


    Agreed - for the "supported" configurations, it works.

    hth,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] pci: print out DMA mask info

    On Fri, Oct 10, 2008 at 04:32:07PM +0900, FUJITA Tomonori wrote:
    ....
    > > > Well, that's because I wrote gart's alloc_coherent and introduced
    > > > dma_alloc_coherent_mask.

    > >
    > > oh. it is in tip

    >
    > Yeah, it's in tip. But the current gart code uses coherent_dma_mask
    > properly (GART in tip works in the same way as the current
    > GART). IIRC, other X86 hardware IOMMUs (VT-d, Calgary, AMD) uses
    > dma_mask in dma_alloc_coherent (AMD in tip uses coherent_dma_mask).


    This is a bug. Care to submit a patch to fix it?
    I don't have any of the docs or HW (VT-d, Calgary) to test it.


    > > then can we remove consistent_dma_mask? just use dma_mask instead for all.

    >
    > I don't think we can. One architecture needs it. The above usb
    > chip seems to need it.


    As noted before, several PCI-X devices support 64-bit DMA for payload
    data but only 32-bit DMA for control data.

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] pci: print out DMA mask info

    On Thu, Oct 09, 2008 at 04:05:57PM -0700, Yinghai Lu wrote:
    > Grant Grundler wrote:
    > > On Thu, Oct 09, 2008 at 02:51:32PM -0700, Yinghai Lu wrote:
    > >> On Thu, Oct 9, 2008 at 2:35 PM, Matthew Wilcox wrote:
    > >>> Why's that interesting to the sysadmin of the machine? To the driver
    > >>> writer, certainly. But what's the use of it to the people using the
    > >>> machine?

    > > ...
    > >> make linux kernel act like black box as other os?

    > >
    > > I don't understand your reply.
    > > If someone thinks linux is a black box, printing this message won't help them.
    > >

    > could find out easily why some driver doesn't set dma mask correctly.
    > like why
    > qlogic qla2xxx only set consistent to 64bit,
    > emulex lpfc not set consistent to 64bit


    I agree making the information available is a good idea. It's just
    not going to help anyone 99% of the time and isn't a requirement for
    booting the machine.

    > >
    > > "To flag use of bounce buffer or other suboptimal behaviors" could be debated.
    > >
    > >
    > > Regarding associating the output with other PCI messages, I'd hope the fact
    > > that the /sys entry is in the same directory as other sys files would be
    > > enough clue to associate those together. e.g.:
    > > grundler <2068>cd /sys/bus/pci/devices/0000\:01\:00.0/
    > > grundler <2069>ls
    > > broken_parity_status driver@ irq resource0 subsystem_device
    > > bus@ enable local_cpus resource1 subsystem_vendor
    > > class i2c-0/ modalias resource3 uevent
    > > config i2c-1/ power/ rom vendor
    > > device i2c-2/ resource subsystem@
    > >

    >
    > add dma_mask coherent_dma_mask here?


    Yes, if there is no other more obvious place.
    It's just a suggestion which I happen to think is better than
    adding more boot time messages.

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] pci: print out DMA mask info

    On Fri, Oct 10, 2008 at 08:48:08AM -0700, Jesse Barnes wrote:
    ....
    > Another option would be to add a 'warn_dma_mask=0xxxxxxxxx' boot option that
    > would trigger in the actual DMA mask setting routines. It would let you
    > choose the mask you'd like to see warnings about. Yinghai?


    No, please don't. We have too many command line options already.

    Dumping dma_mask and dma_consistent_mask from /sys is not hard.
    I'd prefer Yinghai get credit for doing this since he's raised the issue
    and took the time to submit a patch.

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] pci: print out DMA mask info

    On Fri, Oct 10, 2008 at 10:18:33AM -0700, Roland Dreier wrote:
    > > Open-coding DMA_BIT_MASK() within your driver means that we no longer
    > > have a canonical list of DMA masks in one place. Instead we have to
    > > grep the entire tree and come up with more-or-less complex scripts to
    > > figure out which bit masks are actually in use.

    >
    > Out of curiousity, why do we care about that list?


    Originally, I used to track down IO perf issues when porting drivers to ia64.

    But knowing the dma masks in use on specific platforms might allow
    folks to disable DMA_ZONE (like ia64 since it's always guarateed
    either a SWIOTLB or real IOMMU).

    Any other uses?

    thanks,
    grant

    >
    > - R.
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH] pci: print out DMA mask info

    On Fri, 10 Oct 2008 16:45:08 -0600
    Grant Grundler wrote:

    > On Fri, Oct 10, 2008 at 11:40:56AM +0900, FUJITA Tomonori wrote:
    > > IIRC, except for one SGI architecture, coherent_dma_mask is
    > > meaningless, dma_mask is always equal to coherent_dma_mask.

    >
    > Not correct. Several PCI-X devices can only do 32-bit DMA to control
    > data but can do 64-bit DMA for payload data. I don't have the list off
    > the top of my head but that is the origin of coherent DMA mask.


    Thanks. I misunderstood coherent_dma_mask. I needed to read several
    old mails (posted in 2002 and 2003) in ia64 mailing list.


    > > Lots of
    > > IOMMU implementations ignore coherent_dma_mask and use dma_mask for
    > > alloc_coherent().

    >
    > That sounds like a bug. And I don't think it's "lots".


    Maybe it's not "lots" but seems that only IA64 and x86 non-hardware
    IOMMU code (pci-nommu.c and GART) use coherent_dma_mask for
    alloc_coherent.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. [PATCH] pci: show dma_mask bits in /sys

    Grant prefer to add it /sys instead of showing in bootlog

    so could catch if the driver set the correct dma_mask.

    Signed-off-by: Yinghai Lu

    ---
    drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
    1 file changed, 17 insertions(+)

    Index: linux-2.6/drivers/pci/pci-sysfs.c
    ================================================== =================
    --- linux-2.6.orig/drivers/pci/pci-sysfs.c
    +++ linux-2.6/drivers/pci/pci-sysfs.c
    @@ -169,6 +169,21 @@ numa_node_show(struct device *dev, struc
    #endif

    static ssize_t
    +dma_mask_bits_show(struct device *dev, struct device_attribute *attr, char *buf)
    +{
    + struct pci_dev *pdev = to_pci_dev(dev);
    +
    + return sprintf (buf, "%d\n", fls64(pdev->dma_mask));
    +}
    +
    +static ssize_t
    +consistent_dma_mask_bits_show(struct device *dev, struct device_attribute *attr,
    + char *buf)
    +{
    + return sprintf (buf, "%d\n", fls64(dev->coherent_dma_mask));
    +}
    +
    +static ssize_t
    msi_bus_show(struct device *dev, struct device_attribute *attr, char *buf)
    {
    struct pci_dev *pdev = to_pci_dev(dev);
    @@ -223,6 +238,8 @@ struct device_attribute pci_dev_attrs[]
    #ifdef CONFIG_NUMA
    __ATTR_RO(numa_node),
    #endif
    + __ATTR_RO(dma_mask_bits),
    + __ATTR_RO(consistent_dma_mask_bits),
    __ATTR(enable, 0600, is_enabled_show, is_enabled_store),
    __ATTR(broken_parity_status,(S_IRUGO|S_IWUSR),
    broken_parity_status_show,broken_parity_status_sto re),

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH] pci: show dma_mask bits in /sys

    On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:
    > Grant prefer to add it /sys instead of showing in bootlog
    >
    > so could catch if the driver set the correct dma_mask.


    I still don't think this is useful information to be exposing.

    --
    Matthew Wilcox Intel Open Source Technology Centre
    "Bill, look, we understand that you're interested in selling us this
    operating system, but compare it to ours. We can't possibly take such
    a retrograde step."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH] pci: show dma_mask bits in /sys

    On Wed, Oct 22, 2008 at 8:28 PM, Matthew Wilcox wrote:
    > On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:
    >> Grant prefer to add it /sys instead of showing in bootlog
    >>
    >> so could catch if the driver set the correct dma_mask.

    >
    > I still don't think this is useful information to be exposing.
    >


    RHEL 4.6 driver sata_mv is very run out of gart IOMMU, and need iommu
    apterture to be 512M...
    when loading is high, and it turns out every those card support 64bit
    DMA, the driver DID NOT set dma to 64bit
    so it still use 32 bit...

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH] pci: show dma_mask bits in /sys

    On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:
    > Grant prefer to add it /sys instead of showing in bootlog
    >
    > so could catch if the driver set the correct dma_mask.
    >
    > Signed-off-by: Yinghai Lu
    >
    > ---
    > drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
    > 1 file changed, 17 insertions(+)
    >
    > Index: linux-2.6/drivers/pci/pci-sysfs.c
    > ================================================== =================
    > --- linux-2.6.orig/drivers/pci/pci-sysfs.c
    > +++ linux-2.6/drivers/pci/pci-sysfs.c
    > @@ -169,6 +169,21 @@ numa_node_show(struct device *dev, struc
    > #endif
    >
    > static ssize_t
    > +dma_mask_bits_show(struct device *dev, struct device_attribute *attr, char *buf)
    > +{
    > + struct pci_dev *pdev = to_pci_dev(dev);
    > +
    > + return sprintf (buf, "%d\n", fls64(pdev->dma_mask));


    Is there any reason to use %d instead of "0x%x" ?
    I'd much rather see this dumped in hex.

    > +}
    > +
    > +static ssize_t
    > +consistent_dma_mask_bits_show(struct device *dev, struct device_attribute *attr,
    > + char *buf)
    > +{
    > + return sprintf (buf, "%d\n", fls64(dev->coherent_dma_mask));
    > +}
    > +
    > +static ssize_t
    > msi_bus_show(struct device *dev, struct device_attribute *attr, char *buf)
    > {
    > struct pci_dev *pdev = to_pci_dev(dev);
    > @@ -223,6 +238,8 @@ struct device_attribute pci_dev_attrs[]
    > #ifdef CONFIG_NUMA
    > __ATTR_RO(numa_node),
    > #endif
    > + __ATTR_RO(dma_mask_bits),
    > + __ATTR_RO(consistent_dma_mask_bits),
    > __ATTR(enable, 0600, is_enabled_show, is_enabled_store),
    > __ATTR(broken_parity_status,(S_IRUGO|S_IWUSR),
    > broken_parity_status_show,broken_parity_status_sto re),


    Otherwise looks good to me.

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH] pci: show dma_mask bits in /sys

    On Wed, Oct 22, 2008 at 09:28:33PM -0600, Matthew Wilcox wrote:
    > On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:
    > > Grant prefer to add it /sys instead of showing in bootlog
    > >
    > > so could catch if the driver set the correct dma_mask.

    >
    > I still don't think this is useful information to be exposing.


    It's useful for anyone involved with device drivers - we agree that's
    a very limited subset of users. I certainly get fed up with trying
    to figure out which dma_mask each driver is using since in some
    cases it might vary depending on which HW is installed and which
    kernel is running.

    If the /sys patch added a PCI_DEBUG option to the kernel,
    would that work for you?
    I'm not keen on that but just looking for alternatives.
    Many other subsystems (SCSI, ACPI, PM, HID, ...) have a FOO_DEBUG option.

    Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
    grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
    6288 6296 264893
    grundler@gsyprf3:/usr/src/linux-2.6$ find /proc ! -type d | wc
    find: `/proc/tty/driver': Permission denied
    ....
    4104 4104 100797

    Pruning some of the crap out of there sounds like another task suitable for
    "kernel janitor" project.
    /me runs and hides

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH] pci: show dma_mask bits in /sys

    On Wed, Oct 22, 2008 at 11:48 PM, Grant Grundler
    wrote:
    > On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:
    >> Grant prefer to add it /sys instead of showing in bootlog
    >>
    >> so could catch if the driver set the correct dma_mask.
    >>
    >> Signed-off-by: Yinghai Lu
    >>
    >> ---
    >> drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
    >> 1 file changed, 17 insertions(+)
    >>
    >> Index: linux-2.6/drivers/pci/pci-sysfs.c
    >> ================================================== =================
    >> --- linux-2.6.orig/drivers/pci/pci-sysfs.c
    >> +++ linux-2.6/drivers/pci/pci-sysfs.c
    >> @@ -169,6 +169,21 @@ numa_node_show(struct device *dev, struc
    >> #endif
    >>
    >> static ssize_t
    >> +dma_mask_bits_show(struct device *dev, struct device_attribute *attr, char *buf)
    >> +{
    >> + struct pci_dev *pdev = to_pci_dev(dev);
    >> +
    >> + return sprintf (buf, "%d\n", fls64(pdev->dma_mask));

    >
    > Is there any reason to use %d instead of "0x%x" ?
    > I'd much rather see this dumped in hex.


    that is bits, so it will be 64, 41 instead of 0xfffff

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH] pci: show dma_mask bits in /sys

    Grant Grundler wrote:

    > Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
    > grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
    > 6288 6296 264893


    /sys is full of symlinks which /proc is not.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (GNU/Linux)

    iEYEABECAAYFAkkAOBwACgkQXKSJPmm5/E491ACfQHCL6A/X5bT9QVrdCFfrNe+X
    x28An0aeL+VNEgmPqgETIJUkIsZ0/ydP
    =WuYi
    -----END PGP SIGNATURE-----


  16. Re: [PATCH] pci: show dma_mask bits in /sys

    On Thu, Oct 23, 2008 at 12:44:12AM -0600, Grant Grundler wrote:
    >
    > Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
    > grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
    > 6288 6296 264893


    Is this causing some kind of problem for your systems?

    /sys shows far more information than /proc does, so of course it would
    be larger in quantity.

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH] pci: show dma_mask bits in /sys

    Greg KH wrote:
    > On Thu, Oct 23, 2008 at 12:44:12AM -0600, Grant Grundler wrote:
    >> Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
    >> grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
    >> 6288 6296 264893

    >
    > Is this causing some kind of problem for your systems?
    >
    > /sys shows far more information than /proc does, so of course it would
    > be larger in quantity.
    >


    Furthermore, it is actually structured as individual data items; a lot
    of /proc files are aggregate freeform data.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH] pci: show dma_mask bits in /sys

    On Wed, Oct 22, 2008 at 11:51:36PM -0700, Yinghai Lu wrote:
    > On Wed, Oct 22, 2008 at 11:48 PM, Grant Grundler
    > wrote:
    > > On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:
    > >> Grant prefer to add it /sys instead of showing in bootlog
    > >>
    > >> so could catch if the driver set the correct dma_mask.
    > >>
    > >> Signed-off-by: Yinghai Lu
    > >>
    > >> ---
    > >> drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
    > >> 1 file changed, 17 insertions(+)
    > >>
    > >> Index: linux-2.6/drivers/pci/pci-sysfs.c
    > >> ================================================== =================
    > >> --- linux-2.6.orig/drivers/pci/pci-sysfs.c
    > >> +++ linux-2.6/drivers/pci/pci-sysfs.c
    > >> @@ -169,6 +169,21 @@ numa_node_show(struct device *dev, struc
    > >> #endif
    > >>
    > >> static ssize_t
    > >> +dma_mask_bits_show(struct device *dev, struct device_attribute *attr, char *buf)
    > >> +{
    > >> + struct pci_dev *pdev = to_pci_dev(dev);
    > >> +
    > >> + return sprintf (buf, "%d\n", fls64(pdev->dma_mask));

    > >
    > > Is there any reason to use %d instead of "0x%x" ?
    > > I'd much rather see this dumped in hex.

    >
    > that is bits, so it will be 64, 41 instead of 0xfffff


    Sorry - I missed the fls64(). Looks good to me.

    We only need to know if willy agrees to how/when to
    limit when this is available.

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH] pci: show dma_mask bits in /sys

    On Thu, Oct 23, 2008 at 08:39:23AM -0700, Greg KH wrote:
    > On Thu, Oct 23, 2008 at 12:44:12AM -0600, Grant Grundler wrote:
    > >
    > > Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
    > > grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
    > > 6288 6296 264893

    >
    > Is this causing some kind of problem for your systems?


    Nope. Just an observation on the "forest" (vs individual "trees").

    > /sys shows far more information than /proc does, so of course it would
    > be larger in quantity.


    Yes - and /sys is better organized (hierarchial in general).
    But it's getting harder to find stuff because there is so much now.
    Any comments on adding DMA attributes (e.g. dma_mask_bits) to /sys?

    Willy has objected and I'm waiting to hear if he's ok with limiting
    this to a DEBUG compile time flag.

    thanks,
    grant
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH] pci: show dma_mask bits in /sys

    On Thu, Oct 23, 2008 at 01:36:52PM -0600, Grant Grundler wrote:
    > On Thu, Oct 23, 2008 at 08:39:23AM -0700, Greg KH wrote:
    > > On Thu, Oct 23, 2008 at 12:44:12AM -0600, Grant Grundler wrote:
    > > >
    > > > Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
    > > > grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
    > > > 6288 6296 264893

    > >
    > > Is this causing some kind of problem for your systems?

    >
    > Nope. Just an observation on the "forest" (vs individual "trees").
    >
    > > /sys shows far more information than /proc does, so of course it would
    > > be larger in quantity.

    >
    > Yes - and /sys is better organized (hierarchial in general).
    > But it's getting harder to find stuff because there is so much now.
    > Any comments on adding DMA attributes (e.g. dma_mask_bits) to /sys?


    Sorry, wasn't paying attention. All I ask is that if you do add new
    sysfs files, you document them in the proper format in
    Documentation/ABI/

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast