From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Brugger Date: Thu, 19 Mar 2020 15:34:12 +0100 Subject: [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero In-Reply-To: <20200319135641.GB12659@twin.jikos.cz> References: <20200319123006.37578-1-wqu@suse.com> <20200319123006.37578-3-wqu@suse.com> <49c5af50-8c09-9b49-ab44-ebe5eb9a652c@gmail.com> <20200319135641.GB12659@twin.jikos.cz> Message-ID: <46e58bc7-4a4c-fa2a-33cd-0e8df65d6bac@suse.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 19/03/2020 14:56, David Sterba wrote: > On Thu, Mar 19, 2020 at 02:33:28PM +0100, Matthias Brugger wrote: >>> dlen -= out_len; >>> >>> res += out_len; >>> + >>> + /* >>> + * If the 4 bytes header does not fit to the rest of the page we >>> + * have to move to next one, or we read some garbage. >>> + */ >>> + mod_page = tot_in % PAGE_SIZE; >> >> in U-Boot we use 4K page sizes, but the OS could use another page size (16K or >> 64k). Would we need to adapt that code to reflect which page size is used on the >> medium we want to access? > > Yes, it is the 'sectorsize' as it's set up in fs_info or it's equivalent > in uboot. For kernel the page size == sectorsize is kind of implicit and > verified at mount time. > Does this mean we would need to add a Kconfig option to set the sectorsize in U-Boot? Regards, Matthias