[PATCH] Staging: comedi: drivers: fixed errors warning coding style issue
Fixed a coding style issue. Signed-off-by: sunnypranay --- drivers/staging/comedi/drivers.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c index 750a6ff3c03c..76395de100a6 100644 --- a/drivers/staging/comedi/drivers.c +++ b/drivers/staging/comedi/drivers.c @@ -133,7 +133,7 @@ EXPORT_SYMBOL_GPL(comedi_alloc_subdevices); * On success, @s->readback points to the first element of the array, which * is zero-filled. The low-level driver is responsible for updating its * contents. @s->insn_read will be set to comedi_readback_insn_read() - * unless it is already non-NULL. + * Unless it is already non-NULL. * * Returns 0 on success, -EINVAL if the subdevice has no channels, or * -ENOMEM on allocation failure. @@ -282,8 +282,20 @@ EXPORT_SYMBOL_GPL(comedi_readback_insn_read); * continue waiting or some other value to stop waiting (generally 0 if the * condition occurred, or some error value). * - * Returns -ETIMEDOUT if timed out, otherwise the return value from the - * callback function. + * Redback_insn_read() - A generic (*insn_read) for subdevice readback. + * @dev: COMEDI device. + * @s: COMEDI subdevice. + * @insn: COMEDI instruction. + * @data: Pointer to return the readback data. + * Handles the %INSN_READ instruction for subdevices that use the readback + * array allocated by comedi_alloc_subdev_readback(). It may be used + * directly as the subdevice's handler (@s->insn_read) or called via a + * wrapper. + * @insn->n is normally 1, which will read a single value. If higher, the + * same element of the readback array will be read multiple times. + * Returns @insn->n on success, + * or -EINVAL if @s->readback is NULL.turns -ETIMEDOUT if timed out, + * otherwise the return value from the callback function. */ int comedi_timeout(struct comedi_device *dev, struct comedi_subdevice *s, -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: comedi: drivers: fixed errors warning coding style issue
On Sun, Feb 16, 2020 at 01:45:18PM +0530, sunnypranay wrote: > Fixed a coding style issue. What issue? > > Signed-off-by: sunnypranay We need a "real" name here, one that you use for documents. > --- > drivers/staging/comedi/drivers.c | 18 +++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/comedi/drivers.c > b/drivers/staging/comedi/drivers.c > index 750a6ff3c03c..76395de100a6 100644 > --- a/drivers/staging/comedi/drivers.c > +++ b/drivers/staging/comedi/drivers.c > @@ -133,7 +133,7 @@ EXPORT_SYMBOL_GPL(comedi_alloc_subdevices); > * On success, @s->readback points to the first element of the array, which > * is zero-filled. The low-level driver is responsible for updating its > * contents. @s->insn_read will be set to comedi_readback_insn_read() > - * unless it is already non-NULL. > + * Unless it is already non-NULL. > * > * Returns 0 on success, -EINVAL if the subdevice has no channels, or > * -ENOMEM on allocation failure. > @@ -282,8 +282,20 @@ EXPORT_SYMBOL_GPL(comedi_readback_insn_read); > * continue waiting or some other value to stop waiting (generally 0 if the > * condition occurred, or some error value). > * > - * Returns -ETIMEDOUT if timed out, otherwise the return value from the > - * callback function. > + * Redback_insn_read() - A generic (*insn_read) for subdevice readback. > + * @dev: COMEDI device. > + * @s: COMEDI subdevice. > + * @insn: COMEDI instruction. > + * @data: Pointer to return the readback data. > + * Handles the %INSN_READ instruction for subdevices that use the readback > + * array allocated by comedi_alloc_subdev_readback(). It may be used > + * directly as the subdevice's handler (@s->insn_read) or called via a > + * wrapper. > + * @insn->n is normally 1, which will read a single value. If higher, the > + * same element of the readback array will be read multiple times. > + * Returns @insn->n on success, > + * or -EINVAL if @s->readback is NULL.turns -ETIMEDOUT if timed out, > + * otherwise the return value from the callback function. Where did all of that come from? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Documentation: DMA-API-HOWTO.txt: fixed grammer issues Fixed some of the grammer issues in DMA-API-HOWTO.txt using the software grammerly.
From: mpranay
---
Documentation/DMA-API-HOWTO.txt | 628 +++
drivers/staging/comedi/drivers.c | 2 +-
2 files changed, 311 insertions(+), 319 deletions(-)
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 358d495456d1..fa163470fde7 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -31,7 +31,7 @@ I/O devices use a third kind of address: a "bus address". If
a device has
registers at an MMIO address, or if it performs DMA to read or write system
memory, the addresses used by the device are bus addresses. In some
systems, bus addresses are identical to CPU physical addresses, but in
-general they are not. IOMMUs and host bridges can produce arbitrary
+general, they are not. IOMMUs and host bridges can produce arbitrary
mappings between physical and bus addresses.
From a device's point of view, DMA uses the bus address space, but it may
@@ -89,7 +89,7 @@ RAM.
So that Linux can use the dynamic DMA mapping, it needs some help from the
drivers, namely it has to take into account that DMA addresses should be
-mapped only for the time they are actually used and unmapped after the DMA
+mapped only for the time they are used and unmapped after the DMA
transfer.
The following API will work of course even on platforms where no such
@@ -102,9 +102,9 @@ pci_map_*() interfaces.
First of all, you should make sure::
- #include
+ #include
-is in your driver, which provides the definition of dma_addr_t. This type
+is in your driver, which defines dma_addr_t. This type
can hold any valid DMA address for the platform and should be used
everywhere you hold a DMA address returned from the DMA mapping functions.
@@ -142,7 +142,7 @@ in the same cache line, and one of them could be
overwritten.)
Also, this means that you cannot take the return of a kmap()
call and DMA to/from that. This is similar to vmalloc().
-What about block I/O and networking buffers? The block I/O and
+What about the block I/O and networking buffers? The block I/O and
networking subsystems make sure that the buffers they use are valid
for you to DMA from/to.
@@ -163,35 +163,34 @@ your devices DMA addressing capabilities.
This is performed via a call to dma_set_mask_and_coherent()::
- int dma_set_mask_and_coherent(struct device *dev, u64 mask);
+ int dma_set_mask_and_coherent(struct device *dev, u64 mask);
which will set the mask for both streaming and coherent APIs together. If you
have some special requirements, then the following two separate calls can be
used instead:
- The setup for streaming mappings is performed via a call to
- dma_set_mask()::
+ The setup for streaming mappings is performed via a call to
+ dma_set_mask()::
- int dma_set_mask(struct device *dev, u64 mask);
+ int dma_set_mask(struct device *dev, u64 mask);
- The setup for consistent allocations is performed via a call
- to dma_set_coherent_mask()::
+ The setup for consistent allocations is performed via a call
+ to dma_set_coherent_mask()::
- int dma_set_coherent_mask(struct device *dev, u64 mask);
+ int dma_set_coherent_mask(struct device *dev, u64 mask);
-Here, dev is a pointer to the device struct of your device, and mask is a bit
-mask describing which bits of an address your device supports. Often the
+Here, dev is a pointer to the device struct of your device, and the mask is a
+bit mask describing which bits of an address your device supports. Often the
device struct of your device is embedded in the bus-specific device struct of
your device. For example, &pdev->dev is a pointer to the device struct of a
PCI device (pdev is a pointer to the PCI device struct of your device).
-These calls usually return zero to indicated your device can perform DMA
-properly on the machine given the address mask you provided, but they might
+These calls usually return zero to indicate your device can perform DMA
+properly on the machine given the address mask, you provided, but they might
return an error if the mask is too small to be supportable on the given
system. If it returns non-zero, your device cannot perform DMA properly on
this platform, and attempting to do so will result in undefined behavior.
You must not use DMA on this device unless the dma_set_mask family of
-functions has returned success.
+functions have returned success.
This means that in the failure case, you have two options:
@@ -205,19 +204,19 @@ them for the kernel messages to find out exactly why.
The standard 64-bit addressing device would do something like this::
- if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
- dev_warn(dev, "mydev: No suitable DMA available\n");
- goto ignore_this_device;
- }
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)))
Re: [PATCH] Documentation: DMA-API-HOWTO.txt: fixed grammer issues Fixed some of the grammer issues in DMA-API-HOWTO.txt using the software grammerly.
On 2/16/20 6:16 AM, sunnypranay wrote: > From: mpranay > s/grammer/grammar/ et al. Missing Signed-off-by: > --- > Documentation/DMA-API-HOWTO.txt | 628 +++ > drivers/staging/comedi/drivers.c | 2 +- The /comedi/ part of this patch should not be here... and it is also wrong. > 2 files changed, 311 insertions(+), 319 deletions(-) > > diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt > index 358d495456d1..fa163470fde7 100644 > --- a/Documentation/DMA-API-HOWTO.txt > +++ b/Documentation/DMA-API-HOWTO.txt > @@ -102,9 +102,9 @@ pci_map_*() interfaces. > > First of all, you should make sure:: > > - #include > + #include what is the change above? > @@ -142,7 +142,7 @@ in the same cache line, and one of them could be > overwritten.) > Also, this means that you cannot take the return of a kmap() > call and DMA to/from that. This is similar to vmalloc(). > > -What about block I/O and networking buffers? The block I/O and > +What about the block I/O and networking buffers? The block I/O and no thanks. > networking subsystems make sure that the buffers they use are valid > for you to DMA from/to. > > @@ -163,35 +163,34 @@ your devices DMA addressing capabilities. > > This is performed via a call to dma_set_mask_and_coherent():: > > - int dma_set_mask_and_coherent(struct device *dev, u64 mask); > + int dma_set_mask_and_coherent(struct device *dev, u64 mask); what is changed in the lines above? > > which will set the mask for both streaming and coherent APIs together. If > you > have some special requirements, then the following two separate calls can be > used instead: > > - The setup for streaming mappings is performed via a call to > - dma_set_mask():: > + The setup for streaming mappings is performed via a call to > + dma_set_mask():: > > - int dma_set_mask(struct device *dev, u64 mask); > + int dma_set_mask(struct device *dev, u64 mask); > > - The setup for consistent allocations is performed via a call > - to dma_set_coherent_mask():: > + The setup for consistent allocations is performed via a call > + to dma_set_coherent_mask():: > > - int dma_set_coherent_mask(struct device *dev, u64 mask); > + int dma_set_coherent_mask(struct device *dev, u64 mask); Too much invisible changes. What is this? > > -These calls usually return zero to indicated your device can perform DMA > -properly on the machine given the address mask you provided, but they might > +These calls usually return zero to indicate your device can perform DMA good > +properly on the machine given the address mask, you provided, but they might added comma not good. > return an error if the mask is too small to be supportable on the given > system. If it returns non-zero, your device cannot perform DMA properly on > this platform, and attempting to do so will result in undefined behavior. > You must not use DMA on this device unless the dma_set_mask family of > -functions has returned success. > +functions have returned success. wrong. Subject is "family", not "functions". [snip] > @@ -278,7 +277,7 @@ Types of DMA mappings > > There are two types of DMA mappings: > > -- Consistent DMA mappings which are usually mapped at driver > +- Consistent DMA mappings which are usually mapped at a driver no thanks. >initialization, unmapped at the end and for which the hardware should >guarantee that the device and the CPU can access the data >in parallel and will see updates made by each other without any > @@ -287,40 +286,36 @@ There are two types of DMA mappings: >Think of "consistent" as "synchronous" or "coherent". > >The current default is to return consistent memory in the low 32 > - bits of the DMA space. However, for future compatibility you should > - set the consistent mask even if this default is fine for your > - driver. > + bits of the DMA space. However, for future compatibility, you should set > a consistent mask even if this default is fine for your driver. text line too long. We try to limit doc text lines to < 80 characters. > - Consistent DMA memory does not preclude the usage of > - proper memory barriers. The CPU may reorder stores to > - consistent memory just as it may normal memory. Example: > - if it is important for the device to see the first word > - of a descriptor updated before the second, you must do > - something like:: > +Consistent DMA memory does not preclude the usage of > +proper memory barriers. The CPU may reorder stores to > +consistent memory just as it may normal memory. Example: > +if the device needs to see the first word > +of a descriptor updated before the second, you must do > +something like:: why the indentation change?
Re: [PATCH] Documentation: DMA-API-HOWTO.txt: fixed grammer issues Fixed some of the grammer issues in DMA-API-HOWTO.txt using the software grammerly.
On Sun, Feb 16, 2020 at 07:46:58PM +0530, sunnypranay wrote: > From: mpranay > > --- > Documentation/DMA-API-HOWTO.txt | 628 +++ > drivers/staging/comedi/drivers.c | 2 +- > 2 files changed, 311 insertions(+), 319 deletions(-) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch does not have a Signed-off-by: line. Please read the kernel file, Documentation/SubmittingPatches and resend it after adding that line. Note, the line needs to be in the body of the email, before the patch, not at the bottom of the patch or in the email signature. - Your patch did many different things all at once, making it difficult to review. All Linux kernel patches need to only do one thing at a time. If you need to do multiple things (such as clean up all coding style issues in a file/driver), do it in a sequence of patches, each one doing only one thing. This will make it easier to review the patches to ensure that they are correct, and to help alleviate any merge issues that larger patches can cause. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. - It looks like you did not use your "real" name for the patch on either the Signed-off-by: line, or the From: line (both of which have to match). Please read the kernel file, Documentation/SubmittingPatches for how to do this correctly. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 1/2] staging: exfat: remove DOSNAMEs.
> I think you might need to rebase again, this patch doesn't apply at all to my > tree :( Thanks for your comments. I'll try to rebase with 'staging-next' branch. Is this correct? -- Kohada Tetsuhiro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: exfat: remove DOSNAMEs.
On Mon, Feb 17, 2020 at 01:54:07AM +, kohada.tetsuh...@dc.mitsubishielectric.co.jp wrote: > > I think you might need to rebase again, this patch doesn't apply at all to > > my tree :( > > Thanks for your comments. > I'll try to rebase with 'staging-next' branch. > Is this correct? Yes it is, thanks. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/2] staging: exfat: remove DOSNAMEs.
remove 'dos_name','short_name' and related definitions.
'dos_name' and 'short_name' are definitions before VFAT.
These are never used in exFAT.
Signed-off-by: Tetsuhiro Kohada
---
Changes in v3:
- Rebase to staging-next.
Changes in v2:
- Rebase to linux-next-next-20200213.
drivers/staging/exfat/exfat.h | 52 +++--
drivers/staging/exfat/exfat_core.c | 47 +-
drivers/staging/exfat/exfat_super.c | 37
3 files changed, 33 insertions(+), 103 deletions(-)
diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 05e21839b349..ca9d3b5a3076 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -189,8 +189,6 @@ static inline u16 get_row_index(u16 i)
#define MAX_PATH_DEPTH 15 /* max depth of path name */
#define MAX_NAME_LENGTH256 /* max len of filename
including NULL */
#define MAX_PATH_LENGTH260 /* max len of pathname
including NULL */
-#define DOS_NAME_LENGTH11 /* DOS filename length
excluding NULL */
-#define DOS_PATH_LENGTH80 /* DOS pathname length
excluding NULL */
/* file attributes */
#define ATTR_NORMAL0x
@@ -210,9 +208,6 @@ static inline u16 get_row_index(u16 i)
#define NUM_UPCASE 2918
-#define DOS_CUR_DIR_NAME". "
-#define DOS_PAR_DIR_NAME".. "
-
#ifdef __LITTLE_ENDIAN
#define UNI_CUR_DIR_NAME".\0"
#define UNI_PAR_DIR_NAME".\0.\0"
@@ -261,10 +256,6 @@ struct file_id_t {
struct dir_entry_t {
char name[MAX_NAME_LENGTH * MAX_CHARSET_SIZE];
-
- /* used only for FAT12/16/32, not used for exFAT */
- char short_name[DOS_NAME_LENGTH + 2];
-
u32 attr;
u64 Size;
u32 num_subdirs;
@@ -381,33 +372,6 @@ struct dentry_t {
u8 dummy[32];
};
-struct dos_dentry_t {
- u8 name[DOS_NAME_LENGTH];
- u8 attr;
- u8 lcase;
- u8 create_time_ms;
- u8 create_time[2];
- u8 create_date[2];
- u8 access_date[2];
- u8 start_clu_hi[2];
- u8 modify_time[2];
- u8 modify_date[2];
- u8 start_clu_lo[2];
- u8 size[4];
-};
-
-/* MS-DOS FAT extended directory entry (32 bytes) */
-struct ext_dentry_t {
- u8 order;
- u8 unicode_0_4[10];
- u8 attr;
- u8 sysid;
- u8 checksum;
- u8 unicode_5_10[12];
- u8 start_clu[2];
- u8 unicode_11_12[4];
-};
-
/* MS-DOS EXFAT file directory entry (32 bytes) */
struct file_dentry_t {
u8 type;
@@ -482,12 +446,6 @@ struct uentry_t {
struct chain_t clu;
};
-/* DOS name structure */
-struct dos_name_t {
- u8 name[DOS_NAME_LENGTH];
- u8 name_case;
-};
-
/* unicode name structure */
struct uni_name_t {
u16 name[MAX_NAME_LENGTH];
@@ -725,8 +683,7 @@ struct entry_set_cache_t *get_entry_set_in_dir(struct
super_block *sb,
u32 type,
struct dentry_t **file_ep);
void release_entry_set(struct entry_set_cache_t *es);
-s32 count_dos_name_entries(struct super_block *sb, struct chain_t *p_dir,
- u32 type);
+s32 count_entries(struct super_block *sb, struct chain_t *p_dir, u32 type);
void update_dir_checksum(struct super_block *sb, struct chain_t *p_dir,
s32 entry);
void update_dir_checksum_with_entry_set(struct super_block *sb,
@@ -734,9 +691,8 @@ void update_dir_checksum_with_entry_set(struct super_block
*sb,
bool is_dir_empty(struct super_block *sb, struct chain_t *p_dir);
/* name conversion functions */
-s32 get_num_entries_and_dos_name(struct super_block *sb, struct chain_t *p_dir,
-struct uni_name_t *p_uniname, s32 *entries,
-struct dos_name_t *p_dosname);
+s32 get_num_entries(struct super_block *sb, struct chain_t *p_dir,
+ struct uni_name_t *p_uniname, s32 *entries);
u16 calc_checksum_2byte(void *data, s32 len, u16 chksum, s32 type);
/* name resolution functions */
@@ -784,7 +740,7 @@ s32 exfat_count_used_clusters(struct super_block *sb);
/* dir operation functions */
s32 exfat_find_dir_entry(struct super_block *sb, struct chain_t *p_dir,
struct uni_name_t *p_uniname, s32 num_entries,
-struct dos_name_t *p_dosname, u32 type);
+u32 type);
void exfat_delete_dir_entry(struct super_block *sb, struct chain_t *p_dir,
s32 entry, s32 order, s32 num_entries);
void exfat_get_uni_name_from_ext_entry(struct super_block *sb,
diff --git a/drivers/staging/exfat/exfat_core.c
b/drivers/staging/exfat/exfat_core.c
index 5a6
[PATCH v3 2/2] staging: exfat: dedicate count_entries() to sub-dir counting.
count_entries() function is only used to count sub-dirs.
Clarify the role and rename to count_dir_entries().
Signed-off-by: Tetsuhiro Kohada
---
Changes in v3:
- Rebase to staging-next.
Changes in v2:
- Rebase to linux-next-next-20200213.
drivers/staging/exfat/exfat.h | 2 +-
drivers/staging/exfat/exfat_core.c | 8 ++--
drivers/staging/exfat/exfat_super.c | 4 ++--
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index ca9d3b5a3076..c4ef6c2de329 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -683,7 +683,7 @@ struct entry_set_cache_t *get_entry_set_in_dir(struct
super_block *sb,
u32 type,
struct dentry_t **file_ep);
void release_entry_set(struct entry_set_cache_t *es);
-s32 count_entries(struct super_block *sb, struct chain_t *p_dir, u32 type);
+s32 count_dir_entries(struct super_block *sb, struct chain_t *p_dir);
void update_dir_checksum(struct super_block *sb, struct chain_t *p_dir,
s32 entry);
void update_dir_checksum_with_entry_set(struct super_block *sb,
diff --git a/drivers/staging/exfat/exfat_core.c
b/drivers/staging/exfat/exfat_core.c
index 94a10c5984ac..7308e50c0aaf 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -1850,7 +1850,7 @@ s32 exfat_count_ext_entries(struct super_block *sb,
struct chain_t *p_dir,
return count;
}
-s32 count_entries(struct super_block *sb, struct chain_t *p_dir, u32 type)
+s32 count_dir_entries(struct super_block *sb, struct chain_t *p_dir)
{
int i, count = 0;
s32 dentries_per_clu;
@@ -1881,11 +1881,7 @@ s32 count_entries(struct super_block *sb, struct chain_t
*p_dir, u32 type)
if (entry_type == TYPE_UNUSED)
return count;
- if (!(type & TYPE_CRITICAL_PRI) &&
- !(type & TYPE_BENIGN_PRI))
- continue;
-
- if ((type == TYPE_ALL) || (type == entry_type))
+ if (entry_type == TYPE_DIR)
count++;
}
diff --git a/drivers/staging/exfat/exfat_super.c
b/drivers/staging/exfat/exfat_super.c
index f31f771a3dc0..b398114c2604 100644
--- a/drivers/staging/exfat/exfat_super.c
+++ b/drivers/staging/exfat/exfat_super.c
@@ -1468,7 +1468,7 @@ static int ffsReadStat(struct inode *inode, struct
dir_entry_t *info)
p_fs->cluster_size_bits;
}
- count = count_entries(sb, &dir, TYPE_DIR);
+ count = count_dir_entries(sb, &dir);
if (count < 0) {
ret = count; /* propagate error upward */
goto out;
@@ -1535,7 +1535,7 @@ static int ffsReadStat(struct inode *inode, struct
dir_entry_t *info)
info->Size = (u64)count_num_clusters(sb, &dir) <<
p_fs->cluster_size_bits;
- count = count_entries(sb, &dir, TYPE_DIR);
+ count = count_dir_entries(sb, &dir);
if (count < 0) {
ret = count; /* propagate error upward */
goto out;
--
2.25.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
