Dzień dobry,
czy są Państwo otwarci na niezobowiązującą rozmowę na temat fotowoltaiki?
Jako firma specjalizująca się w instalacji i serwisie najlepszych jakościowo
paneli słonecznych na rynku chciałbym przedstawić propozycję, jaką wspólnie z
zespołem przygotowaliśmy dla Państwa obiektu.
Będę w
On Thu 29-08-24 10:33:22, Charlie Jenkins wrote:
> On Thu, Aug 29, 2024 at 10:30:56AM +0200, Michal Hocko wrote:
> > On Thu 29-08-24 00:15:57, Charlie Jenkins wrote:
> > > Some applications rely on placing data in free bits addresses allocated
> > > by mmap. Various architectures (eg. x86, arm64, p
The dependency handling of the Synopsys DesignWare I2C
adapter drivers is going to be changed so that the glue
drivers for the PCI and platform buses depend on
I2C_DESIGNWARE_CORE.
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Heikki Krogerus
---
arch/arc/configs/axs101
Hi guys,
This is a proposal for Kconfig improvement regarding the Synopsys
DesignWare I2C adapter driver.
Changes since v1:
There was one driver that selects I2C_DESIGNWARE_PLATFORM in its
Kconfig which causes an error because I2C_DESIGNWARE_CORE is not
selected.
The drivers Kconfig I'm proposi
On Tue, Sep 3, 2024 at 9:39 AM Vineet Gupta wrote:
>
>
>
> On 8/31/24 23:50, Masahiro Yamada wrote:
> > On Sun, Sep 1, 2024 at 8:02 AM Vineet Gupta wrote:
> >>
> >>
> >> On 8/31/24 03:13, Masahiro Yamada wrote:
> >>> On Sat, Aug 31, 2024 at 7:10 PM Masahiro Yamada
> >>> wrote:
> Commit abe
Hi Charlie,
Le 29/08/2024 à 09:15, Charlie Jenkins a écrit :
The hint address and mmap_flags are necessary to determine if
MAP_BELOW_HINT requirements are satisfied.
Signed-off-by: Charlie Jenkins
---
arch/alpha/kernel/osf_sys.c | 2 ++
arch/arc/mm/mmap.c | 3 +++
arch/a
On Mon, Sep 02, 2024 at 08:08:13PM GMT, Mark Brown wrote:
> When we introduced arch_get_unmapped_area_vmflags() in 961148704acd
> ("mm: introduce arch_get_unmapped_area_vmflags()") we did so as part of
> properly supporting guard pages for shadow stacks on x86_64, which uses
> a custom arch_get_unm
On Mon, Sep 02, 2024 at 08:08:14PM GMT, Mark Brown wrote:
> In preparation for using vm_flags to ensure guard pages for shadow stacks
> supply them as an argument to generic_get_unmapped_area(). The only user
> outside of the core code is the PowerPC book3s64 implementation which is
> trivially wra
On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote:
> As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow
> stack guard gap during placement") our current mmap() implementation does
> not take care to ensure that a new mapping isn't placed with existing
> mappings inside
On Tue, Sep 03, 2024 at 06:49:46PM +0100, Lorenzo Stoakes wrote:
> On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote:
> > On x86 there is a custom arch_get_unmapped_area() which was updated by the
> > above commit to cover this case by specifying a start_gap for allocations
> > with VM_SHAD
On Tue, Sep 03, 2024 at 07:20:02PM GMT, Mark Brown wrote:
> On Tue, Sep 03, 2024 at 06:49:46PM +0100, Lorenzo Stoakes wrote:
> > On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote:
>
> > > On x86 there is a custom arch_get_unmapped_area() which was updated by the
> > > above commit to cover t
* Mark Brown [240902 15:09]:
> When we introduced arch_get_unmapped_area_vmflags() in 961148704acd
> ("mm: introduce arch_get_unmapped_area_vmflags()") we did so as part of
> properly supporting guard pages for shadow stacks on x86_64, which uses
> a custom arch_get_unmapped_area(). Equivalent fea
* Mark Brown [240902 15:09]:
> In preparation for using vm_flags to ensure guard pages for shadow stacks
> supply them as an argument to generic_get_unmapped_area(). The only user
> outside of the core code is the PowerPC book3s64 implementation which is
> trivially wrapping the generic implementa
* Mark Brown [240902 15:09]:
> As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow
> stack guard gap during placement") our current mmap() implementation does
> not take care to ensure that a new mapping isn't placed with existing
> mappings inside it's own guard gaps. This i
On 9/2/24 21:08, Mark Brown wrote:
When we introduced arch_get_unmapped_area_vmflags() in 961148704acd
("mm: introduce arch_get_unmapped_area_vmflags()") we did so as part of
properly supporting guard pages for shadow stacks on x86_64, which uses
a custom arch_get_unmapped_area(). Equivalent feat
On Tue, Sep 03, 2024 at 03:41:49PM -0400, Liam R. Howlett wrote:
> * Mark Brown [240902 15:09]:
> > +static inline unsigned long stack_guard_placement(vm_flags_t vm_flags)
> > +{
> > + if (vm_flags & VM_SHADOW_STACK)
> > + return PAGE_SIZE;
> Is PAGE_SIZE is enough?
It's what x86 cu
Hi Jarkko, Andy,
...
> Heikki Krogerus (7):
> ARC: configs: enable I2C_DESIGNWARE_CORE with I2C_DESIGNWARE_PLATFORM
> ARM: configs: enable I2C_DESIGNWARE_CORE with I2C_DESIGNWARE_PLATFORM
> arm64: defconfig: enable I2C_DESIGNWARE_CORE with
> I2C_DESIGNWARE_PLATFORM
> mips: configs: en
Mark Brown writes:
> In preparation for using vm_flags to ensure guard pages for shadow stacks
> supply them as an argument to generic_get_unmapped_area(). The only user
> outside of the core code is the PowerPC book3s64 implementation which is
> trivially wrapping the generic implementation in th
18 matches
Mail list logo
