On Tue, 10 Mar 2020 11:54:21 +0100, Greg Kroah-Hartman said:
> Now that there is a "real" solution for exfat in the vfs tree queued up
> to be merged in 5.7-rc1 the "old" exfat code in staging can be removed.
>
> Many thanks to Valdis for doing the work to get this into the tree in
> the first plac
On Tue, 03 Mar 2020 03:07:51 +,
"kohada.tetsuh...@dc.mitsubishielectric.co.jp" said:
> > Are you sure this is OK to do? exfat_get_entry_type() does a lot of
> > mapping between values, using a file_dentry_t->type, while
> > fid->type is a file_id_t->type.
> The value that vfs sets to the old
On Mon, 02 Mar 2020 18:57:15 +0900, Tetsuhiro Kohada said:
> Clean up d_entry rebuilding in exfat_rename_file() and move_file().
>
> -Replace memcpy of d_entry with structure copy.
Those look OK.
> -Change to use the value already stored in fid.
> - if (exfat_get_entry_type(epnew) ==
On Thu, 27 Feb 2020 02:14:02 +,
"kohada.tetsuh...@dc.mitsubishielectric.co.jp" said:
> Thanks for comment.
>
> > Then this should have been [PATCH v2], and the fixed version [PATCH
> > v3]
>
> 2nd patch(Additional patch) not include 1st patch(RFC PATCH).
> And the 1st patch has been merged int
On Wed, 26 Feb 2020 15:37:46 +0900, Tetsuhiro Kohada said:
> Completely remove symlink codes and definitions.
> In the previous patch, it was not completely removed.
Then this should have been [PATCH v2], and the fixed version [PATCH v3]
> Signed-off-by: Tetsuhiro Kohada
> ---
And right in here
On Wed, 19 Feb 2020 21:47:38 +0530, you said:
> exfat_fat_sync() is not called anywhere, hence remove it from
> exfat_cache.c and exfat.h
Yes, it's a leftover from the fat/vfat support that got taken out.
Acked-by: Valdis Kletnieks
pgpq4XA0lOzRP.pgp
Description: PGP signature
_
On Wed, 19 Feb 2020 14:57:27 +0900, Tetsuhiro Kohada said:
> Remove symlink feature completely.
>
> Becouse
> -Uses reserved areas(defined in the Microsoft exfat specification), causing
> future incompatibilities.
> -Not described in Microsoft exfat specifications or SD standards.
> -For REMOVABLE
> Idea is simple. Expects that we have a clean filesystem in correct
> state. We load primary/active/main FAT table (just call it FAT1) and all
> changes to filesystem would be done via second non-active FAT table
> (FAT2). At unmount or sync or flush buffer times, FAT2 would be copied
> back to t
On Thu, 13 Feb 2020 16:18:47 -0500, Sasha Levin said:
> >> I was hoping that it would be possible to easily use secondary FAT table
> >> (from TexFAT extension) for redundancy without need to implement full
> >> TexFAT, which could be also backward compatible with systems which do
> >> not impleme
On Fri, 08 Nov 2019 22:32:39 +0100, Arnd Bergmann said:
> Similar to commit 46c9a946d766 ("shmem: use monotonic time for i_generation")
> we should not use the deprecated get_seconds() interface for i_generation.
>
> prandom_u32() is the replacement used in other file systems.
>
> Signed-off-by: Ar
On Tue, 05 Nov 2019 18:05:15 +0100, Greg Kroah-Hartman said:
> This patch breaks the build:
>
> drivers/staging/exfat/exfat_super.c: In function âffsMountVolâ:
> drivers/staging/exfat/exfat_super.c:387:9: error: âFFS_FORMATERRâ
> undeclared
(first use in this function)
> 387 | ret = F
On Mon, 04 Nov 2019 16:33:06 -0800, Christoph Hellwig said:
> On Sun, Nov 03, 2019 at 08:45:06PM -0500, Valdis Kletnieks wrote:
> > There's currently 6 filesystems that have the same #define. Move it
> > into errno.h so it's defined in just one place.
>
> And 4 out of 6 also define EFSBADCRC, so pl
On Mon, 04 Nov 2019 13:04:14 +0300, Dan Carpenter said:
> On Sun, Nov 03, 2019 at 08:45:03PM -0500, Valdis Kletnieks wrote:
> > - if (sector_read(sb, sec, &bp->buf_bh, 1) != FFS_SUCCESS) {
> > + if (sector_read(sb, sec, &bp->buf_bh, 1) != 0) {
>
> It's better to just remove the "!= 0" double ne
On Sun, 03 Nov 2019 10:09:21 -0800, Davidlohr Bueso said:
> The call was not releasing the mutex upon error.
>
> Reported-by: kbuild test robot
> Reported-by: Julia Lawall
> Signed-off-by: Davidlohr Bueso
Yeah, I missed one, thanks for catching it.
Acked-By: Valdis Kletnieks
pgpmwxhzgZnpU
On Wed, 30 Oct 2019 20:04:49 -0700, "Darrick J. Wong" said:
> I would add (d) can we do the same to EFSBADCRC, seeing as f2fs,
> ext4, xfs, and jbd2 all define it the same way?
If this one flies, that's a good candidate for a second patch
pgpCNp_PdIQvD.pgp
Description: PGP signature
___
On Thu, 24 Oct 2019 10:59:04 -0700, Matthew Wilcox said:
> Wouldn't it be better to do this as:
> Patch 1: Change all these defines to -Exxx and remove the stupid
> errno-changing
> blocks like this:
Well, except for the fact that the one for FFS_MEDIAERR required splitting the
uses into -ENODEV
On Thu, 24 Oct 2019 09:29:00 -0700, Joe Perches said:
> > - if (sector_read(sb, sec, &bp->buf_bh, 1) != FFS_SUCCESS) {
> > + if (sector_read(sb, sec, &bp->buf_bh, 1) != 0) {
>
> Probably nicer to just drop the != 0
Again, that's on the to-do list.
pgpW4nZ8xnSkz.pgp
Description: PGP signatur
On Thu, 24 Oct 2019 09:23:24 -0700, Joe Perches said:
> All well and good, but does converting the error code from
> positive to negative have any impact on any of the code
> paths that use these return values?
>
> if (error > 0)
> vs
> if (error < 0)
I was keeping an eye open for tha
On Thu, 24 Oct 2019 09:23:33 -0700, Joe Perches said:
> On Thu, 2019-10-24 at 11:53 -0400, Valdis Kletnieks wrote:
> > if (err) {
> > - if (err == FFS_PERMISSIONERR)
> > + if (err == -EPERM)
> > err = -EPERM;
> > else if (err == FFS_INVALIDPA
On Wed, 16 Oct 2019 16:33:17 -0400, Sasha Levin said:
> It looks like the reason this wasn't made public along with the exFAT
> spec is that TexFAT is pretty much dead - it's old, there are no users
> we are aware of, and digging it out of it's grave to make it public is
> actually quite the heada
On Wed, 16 Oct 2019 10:31:13 -0400, Sasha Levin said:
> On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Roh�r wrote:
> >Now one month passed, so do you have some information when missing parts
> >of documentation like TexFAT would be released to public?
>
> Sure, I'll see if I can get an approval t
The majority of them were totally backwards. Change the logic
so that if DELAYED_SYNC *isn't* in the config, we actually flush to disk
before flagging the file system as clean.
That leaves two calls in the DELAYED_SYNC case. More detailed
analysis is needed to make sure that's what's really need
On Wed, 02 Oct 2019 20:47:03 +0530, Saiyam Doshi said:
> fs_sync() is wrapper to bdev_sync(). When fs_sync is called with
> non-zero argument, bdev_sync gets called.
>
> Most instances of fs_sync is called with false and very few with
> true. Refactor this and makes direct call to bdev_sync() where
We've seen several incorrect patches for fs_sync() calls in the exfat driver.
Add code to the TODO that explains this isn't just a delete code and refactor,
but that actual analysis of when the filesystem should be flushed to disk
needs to be done.
Signed-off-by: Valdis Kletnieks
---
diff --git
On Thu, 19 Sep 2019 05:31:21 +0900, Ju Hyung Park said:
> We should probably ask Valdis on what happened there.
>
> Even the old exFAT v1.2.24 from Galaxy S7 is using "either version 2
> of the License, or (at your option) any later version".
> You can go check it yourself by searching "G930F" fro
On Tue, 17 Sep 2019 12:02:01 +0900, "Namjae Jeon" said:
> We are excited to see this happening and would like to state that we
> appreciate time and
> effort which people put into upstreaming exfat. Thank you!
The hard part - getting Microsoft to OK merging an exfat driver - is done.
All we need
On Tue, 10 Sep 2019 16:09:35 +0300, Dan Carpenter said:
> On Tue, Sep 10, 2019 at 01:58:35PM +0100, Colin Ian King wrote:
> > On 10/09/2019 13:44, Dan Carpenter wrote:
> > > On Fri, Aug 30, 2019 at 07:38:00PM +0100, Colin Ian King wrote:
> > >> Hi,
> > >>
> > >> Static analysis on exfat with Coveri
On Sun, 08 Sep 2019 17:35:36 -, Valentin Vidic said:
> sbi parameter not used inside the function so remove it.
> Also cleanup unused variables generated by this change.
Tread carefully with this sort of patch - there's still a lot of places in the
code
where we have matching pairs of exfat_f
On Sun, 08 Sep 2019 16:10:14 -, Valentin Vidic said:
> Not used in the exfat-fuse implementation and spec defines
> this position should hold the value for CreateUtcOffset.
In that case, rather than removing it, shouldn't we be *adding*
code to properly set it instead?
pgpDFfdaGOzRf.pgp
Desc
On Mon, 02 Sep 2019 15:42:19 +0300, Anatoly Pugachev said:
> is it intentionally that you use
>
> yes "" | make oldconfig
>
> instead of
>
> make olddefconfig
They do something different. 'olddefconfig' just takes the platform or
architecture defconfig and updates it for any new CONFIG_* variabl
On Sat, 31 Aug 2019 07:54:10 +1000, Dave Chinner said:
> The correct place for new filesystem review is where all the
> experienced filesystem developers hang out - that's linux-fsdevel,
> not the driver staging tree.
So far everything's been cc'ed to linux-fsdevel, which has been spending
more t
On Fri, 30 Aug 2019 19:15:23 +0100, Colin King said:
> From: Colin Ian King
>
> The goto after a return is never executed, so it is redundant and can
> be removed.
>
> Addresses-Coverity: ("Structurally dead code")
> Signed-off-by: Colin Ian King
Good catch
> - if (dentry < -1) {
> +
On Thu, 29 Aug 2019 22:56:31 +0200, Pali Roh�r said:
> I'm not really sure if this exfat implementation is fully suitable for
> mainline linux kernel.
>
> In my opinion, proper way should be to implement exFAT support into
> existing fs/fat/ code instead of replacing whole vfat/msdosfs by this
> n
On Thu, 29 Aug 2019 14:14:35 +0200, Pali Roh�r said:
> On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> > The full specification of the filesystem can be found at:
> > https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
>
> This is not truth. This specificati
On Tue, 09 Jul 2019 16:39:31 -, KY Srinivasan said:
> Let me dig up the details here.
In case this helps clarify the chain of events, the code in question
is the Samsung code mentioned here, updated to 5.2 kernel
"We know that Microsoft has done patent troll shakedowns in the past on Lin
On Tue, 09 Jul 2019 08:48:34 -0700, Matthew Wilcox said:
> Interesting analysis. It seems to me that the correct forms would be
> observed if someone suitably senior at Microsoft accepted the work from
> Valdis and submitted it with their sign-off. KY, how about it?
I'd be totally OK with that.
I have an out-of-tree driver for the exfat file system that I beaten into shape
for upstreaming. The driver works, and passes sparse and checkpatch (except
for a number of line-too-long complaints).
Do you want this taken straight to the fs/ tree, or through drivers/staging?
pgpPbWnt1mYai.pgp
De
On Tue, 09 Jul 2019 01:52:20 +0100, Al Viro said:
> On Mon, Jul 08, 2019 at 08:37:42PM -0400, Valdis KlÄtnieks wrote:
> > I have an out-of-tree driver for the exfat file system that I beaten into
> > shape
> > for upstreaming. The driver works, and passes sparse and checkpatch (except
> > for a n
Building with W=1 reports (among other things)
CC [M] drivers/staging/rtl8712/rtl871x_ioctl_linux.o
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1106: warning: Cannot understand
*
on line 1106 - I thought it was a doc line
CC [M] drivers/staging/rtl8712/os_intfs.o
drivers/staging/rtl871
39 matches
Mail list logo
