Ben Dooks wrote:
> The run_dax() prototype is defined in "bus.h" but drivers/dax/super.c
> does not include this. Include bus.h to silece the following sparse
> warning:
>
> drivers/dax/super.c:337:6: warning: symbol 'run_dax' was not declared. Should
> it be static?
A different version of this
Ben Dooks wrote:
> The nd_class is not used outside of drivers/nvdimm/bus.c and thus sparse
> is generating the following warning. Remove this by making it static:
>
> drivers/nvdimm/bus.c:28:14: warning: symbol 'nd_class' was not declared.
> Should it be static?
Reviewed-by: Ira Weiny
>
Currently logic for installing notifications from ACPI devices is
implemented using notify callback in struct acpi_driver. Preparations
are being made to replace acpi_driver with more generic struct
platform_driver, which doesn't contain notify callback. Furthermore
as of now handlers are being
Currently logic for installing notifications from ACPI devices is
implemented using notify callback in struct acpi_driver. Preparations
are being made to replace acpi_driver with more generic struct
platform_driver, which doesn't contain notify callback. Furthermore
as of now handlers are being
Currently terminator line contains redunant characters. Remove them and
also remove a comma at the end.
Signed-off-by: Michal Wilczynski
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index
To use new style of installing event handlers acpi_nfit_notify() needs
to be known inside acpi_nfit_add(). Move acpi_nfit_notify() upwards in
the file, so it can be used inside acpi_nfit_add().
Signed-off-by: Michal Wilczynski
---
drivers/acpi/nfit/core.c | 14 +++---
1 file changed, 7
Currently logic for installing notifications from ACPI devices is
implemented using notify callback in struct acpi_driver. Preparations
are being made to replace acpi_driver with more generic struct
platform_driver, which doesn't contain notify callback. Furthermore
as of now handlers are being
Currently logic for installing notifications from ACPI devices is
implemented using notify callback in struct acpi_driver. Preparations
are being made to replace acpi_driver with more generic struct
platform_driver, which doesn't contain notify callback. Furthermore
as of now handlers are being
Currently logic for installing notifications from ACPI devices is
implemented using notify callback in struct acpi_driver. Preparations
are being made to replace acpi_driver with more generic struct
platform_driver, which doesn't contain notify callback. Furthermore
as of now handlers are being
Currently logic for installing notifications from ACPI devices is
implemented using notify callback in struct acpi_driver. Preparations
are being made to replace acpi_driver with more generic struct
platform_driver, which doesn't contain notify callback. Furthermore
as of now handlers are being
Most drivers set driver_data during .add() callback, but usually
they don't set it back to NULL in case of a failure. Set driver_data to
NULL in acpi_device_probe() to avoid code duplication.
Signed-off-by: Michal Wilczynski
---
drivers/acpi/bus.c | 4 +++-
1 file changed, 3 insertions(+), 1
Introduce new acpi_dev_install_notify_handler() and
acpi_dev_remove_notify_handler(). Those functions are replacing old
installers, and after all drivers switch to the new model, old installers
will be removed.
Make acpi_dev_install_notify_handler() and acpi_dev_remove_notify_handler()
*** IMPORTANT ***
This is part 1 - only drivers in acpi directory to ease up review
process. Rest of the drivers will be handled in separate patchsets.
Currently drivers support ACPI event handlers by defining .notify
callback in acpi_device_ops. This solution is suboptimal as event
handler
The nd_class is not used outside of drivers/nvdimm/bus.c and thus sparse
is generating the following warning. Remove this by making it static:
drivers/nvdimm/bus.c:28:14: warning: symbol 'nd_class' was not declared. Should
it be static?
Signed-off-by: Ben Dooks
---
drivers/nvdimm/bus.c | 2 +-
The security_show function is not used outsid of drivers/nvdimm/dimm_devs.c
and the attribute it is for is also already static. Silence the sparse
warning for this not being declared by making it static. Fixes:
drivers/nvdimm/dimm_devs.c:352:9: warning: symbol 'security_show' was not
declared.
On 6/16/23 09:09, Ben Dooks wrote:
The security_show function is not used outsid of drivers/nvdimm/dimm_devs.c
s/outsid/outside/
and the attribute it is for is also already static. Silence the sparse
warning for this not being declared by making it static. Fixes:
The run_dax() prototype is defined in "bus.h" but drivers/dax/super.c
does not include this. Include bus.h to silece the following sparse
warning:
drivers/dax/super.c:337:6: warning: symbol 'run_dax' was not declared. Should
it be static?
Signed-off-by: Ben Dooks
---
drivers/dax/super.c | 1 +
On 16.06.23 00:00, Vishal Verma wrote:
With DAX memory regions originating from CXL memory expanders or
NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
on a system without enough 'regular' main memory to support the memmap
for it. To avoid this, ensure that all kmem
On 16.06.23 00:00, Vishal Verma wrote:
In preparation for the dax/kmem driver, which can be built as a module,
to use this interface, export it with EXPORT_SYMBOL_GPL().
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Andrew Morton
Cc: David Hildenbrand
Cc: Oscar Salvador
Cc: Dan Williams
Cc:
On 16.06.23 00:00, Vishal Verma wrote:
For memory hotplug to consider MHP_MEMMAP_ON_MEMORY behavior, the
'memmap_on_memory' module parameter was a hard requirement.
In preparation for the dax/kmem driver to use memmap_on_memory
semantics, arrange for the module parameter check to be bypassed
On 16.06.23 00:00, Vishal Verma wrote:
The dax/kmem driver can potentially hot-add large amounts of memory
originating from CXL memory expanders, or NVDIMMs, or other 'device
memories'. There is a chance there isn't enough regular system memory
available to fit ythe memmap for this new memory.
Vishal Verma writes:
> With DAX memory regions originating from CXL memory expanders or
> NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
> on a system without enough 'regular' main memory to support the memmap
> for it. To avoid this, ensure that all kmem managed
Hi, Vishal,
Thanks for your patch!
Vishal Verma writes:
> For memory hotplug to consider MHP_MEMMAP_ON_MEMORY behavior, the
> 'memmap_on_memory' module parameter was a hard requirement.
>
> In preparation for the dax/kmem driver to use memmap_on_memory
> semantics, arrange for the module
23 matches
Mail list logo
